0
私たちは、SpringセキュリティのJdbcTokenStoreを使用してoAuth2アクセストークンを保持しています。同じアプリケーションは、spring-data-jpaにも大きく依存しています。どちらもMySQLデータベースへの接続プールを共有しています。spring-data-jpaとspring-security-oauthのJdbcTokenStoreの間でJdbc接続プールを共有する場合、トランザクションの処理方法は？
Jdbcはデフォルトで自動コミットモードになり、JdbcTokenStoreは自動コミットがオンであるという前提で書かれているようです。明示的に変更をコミットすることはありません。
一方、SpringデータとJPAは書き込み操作のトランザクションを必要とします。アプリケーションは@Transactionalアノテーションを使用します。
私たちは、次の問題を観察している：
- 要求は、（1）：クライアントがアクセストークンを取得します。 JdbcTokenStoreこれをデータベースに挿入します。
- 要求（2）：クライアントは、その後の要求でこのアクセストークンを使用します。トークンがデータベース内に見つからないため、この要求は拒否されます。
この動作は、request（1）のトランザクションがまだコミットされていないと説明できます。
私はSpringの内部についてあまりよく知らないです。次のことが起こる可能性はありますか？
- JPA操作の中には、プールからJDBC接続＃1を取得し、auto-commit = offを設定し、任意の数のSQL文を実行してからコミットします。
- リクエスト（1）：JdbcTokenStoreは同じJDBC接続＃1を取得し、INSERT文を実行します。
- リクエスト（2）：JdbcTokenStoreは別のJDBC接続＃2を取得し、SELECT文を実行します。 （コミットされていないトランザクションは表示されません）
- 一部のJPA操作は、JDBC接続＃1を再度取得し、コミットします。 （oAuthトークンはコミットされました）
これを回避する構成はありますか？