与 JdbcTokenStore 相比，JpaTokenStore 是否有任何缺点？答案

【问题标题】：Does JpaTokenStore have any downsides when compared to JdbcTokenStore for spring security oauth与 JdbcTokenStore 相比，JpaTokenStore 是否有任何缺点？
【发布时间】：2016-11-16 05:58:17
【问题描述】：

我目前在我的应用程序中通过 Hibernate 使用 Jpa。由于spring security oauth2提供了JdbcTokenStore，我就开始使用了。但问题是，我无法使用缓存（应用程序中的所有实体当前共享）。

它以单独的流程访问数据库。

我正在考虑实现由 Jpa 支持的 JpaTokenStore 并利用它带来的缓存优势。

有没有人尝试使用这种方法实现这个/看到任何缺点？

【问题讨论】：

标签： jpa jdbc spring-security spring-security-oauth2

【解决方案1】：

在一个项目中，我使用 JPA 实现了 org.springframework.security.oauth2.client.token.ClientTokenServices 并且没有发现任何问题。我能够使用 JPA 的所有标准功能，包括 @Transactional for JPAClientTokenServices#saveAccessToken

【讨论】：

【解决方案2】：

没有什么能阻止你这样做，很多人确实将 JPA 用于各种事情，但 IMO JPA 并不适合处理身份数据的存储。 JPA 是为在 JDBC 连接（基本上是一个事务）期间缓存数据而设计和优化的，而身份数据通常具有不同且更长的生命周期。如果您使用 JPA 存储长期存在的数据，则必须处理当您在其正常生命周期之外访问它时所发生的后果，例如使用 DTO，最终在一定程度上否定了使用它的好处。

【讨论】：

感谢您的回复。通过“JPA 带来的缓存优势”，我专门指的是二级缓存，而不是事务级缓存。通过使用额外的缓存层，例如 hazelcast/ehcache，我可以避免每次安全调用的 db 往返（因为每个安全都需要验证访问令牌）。我无法完全遵循 DTO 的缺点，因为缓存的 AccessToken（无论主体是否为 DTO/实体），如果底层用户有任何更新，访问和刷新令牌缓存条目可能会失效。
我也可以修改 JdbcTokenStore 以利用外部缓存，但是当您拥有 JPA 时，在大多数情况下，出于性能原因，大多数情况下都会缓存用户对象。所以，我的观点是，最好还是依靠在令牌生成过程中加速的用户缓存