私は現在、アプリケーションでHibernate経由でJpaを使用しています。春のセキュリティoauth2はJdbcTokenStoreを提供して以来、私はそれを使い始めました。しかし、その問題は、キャッシュを使用できないことです（アプリケーション内のすべてのエンティティが現在共有しています）。JpaTokenStoreは、スプリングセキュリティoauthのJdbcTokenStoreと比較して何らかの短所を持っていますか？
別のフローでデータベースにヒットします。
私は実装を考えていますJpa &に裏打ちされたJpaTokenStoreは、それに付属のキャッシュの利点を活用しています。
誰でもこの方法を試しましたか、このアプローチを使用していますか？
私はorg.springframework.security.oauth2.client.token.ClientTokenServicesにJPAを組み込み、何の問題にも気付かなかった1つのプロジェクトでは、私はJPAのすべての標準機能を使用することができました。JPAClientTokenServices#saveAccessToken
JPGを使用している人はたくさんいますが、IMO JPAはストレージの取り扱いには適していませんのIDデータ。 JPAは、JDBC接続（基本的にトランザクション）の間、データをキャッシュするように設計され、最適化されています。一方、IDデータは一般的には異なり、より長い存続期間を持ちます。 JPAを使用して長期間保存したデータを保存する場合、通常の有効期間外にアクセスするとどうなるかの結果に対処する必要があります。 DTOを使用すると、最初にある程度それを使用する利点を否定することになります。
ご回答いただきありがとうございます。 「JPAに付属するキャッシュの利点」では、具体的にはトランザクションレベルのキャッシュではなく第2レベルのキャッシュを指していました。ヘイゼルキャスト/ ehcacheなどの追加のキャッシュ層を使用することで、各セキュアコールがアクセストークンを検証する必要があるため、すべてのセキュアコールのdbラウンドトリップを回避できます。 キャッシュされたAccessToken（プリンシパルがDTO/Entityであるかどうかにかかわらず）、基盤となるユーザーへの更新があればアクセス＆リフレッシュトークンキャッシュエントリを無効にすることができるため、DTOの欠点に完全に追いつかなかった。 –
私はJdbcTokenStoreを外部キャッシュを利用するように変更することもできますが、ほとんどの場合JPAを使用するとほとんどの場合パフォーマンス上の理由からユーザーオブジェクトがキャッシュされます。 私の見解では、トークンの生成中にスピードアップするユーザーキャッシュに頼るほうがよい –