我需要在每次数据库操作之前设置一些上下文(我尝试过使用Oracle的包级变量，但由于包重新编译的一些问题，我将尝试使用 DBMS_SESSION 和/或DBMS_APPLICATION_INFO )，这样我们就可以在任何需要的地方获取特定的用户信息(过程、触发器等)，而不是让数十个数据库连接标识为“JBoss”。
我编写了一个 Java EE 拦截器，用于拦截对 @Stateless bean 的调用。它调用 Oracle 函数来设置一些 session 上下文(查看此问题以获取一些示例代码 How to tell if a transaction is active in a Java EE 6 interceptor )。
我首先担心的是连接池。起初，我认为 Java EE 提供的默认 @PersistenceContext 传播足以保证所有内容都在同一个连接/事务/EntityManager 中运行，并且我只需在拦截器末尾取消设置所有内容(在 finally block )在连接返回到池之前。它看起来有点脆弱，但我认为它可以工作。
然后我发现Hibernate有一个名为hibernate.connection.release_mode的属性 ( Hibernate docs about hibernate.connection.release_mode ， Red Hat docs about org.hibernate.ConnectionReleaseMode )并且使用 JTA 事务时默认和推荐行为是在每个语句后释放连接(尽管文档说了一些关于 < em>重新获取相同的底层连接，这让我很困惑)。
现在我什至不确定我是否可以在拦截器中可靠地设置一些仅对此用户/操作可见的内容，而不会有其他人在我的业务方法中获取相同连接并搞乱的风险我的用户上下文。据我了解，Oracle数据库 session 变量是为连接保留的，而不是为事务或@PersistenceContext保留的(毕竟数据库对持久性上下文一无所知，并且一个连接可以用于多个事务)。
我即将放弃，因为随着我对所涉及的所有技术的实现细节了解更多，这看起来越来越脆弱。 这个用户上下文想法可以实现吗？还是我应该尝试一种完全不同的方法？我如何测试/调试我的实现，以确保不存在任何并发问题？ 我还没有找到任何有用的事件监听器来监视框架行为，并构建一个程序来对服务器进行压力测试投资于我不确定是否应该起作用的东西实在是太费力了。
我正在使用 JBoss AS 7.1、EJB 3.1、Oracle 10g 数据库和 JPA 2.0(由 Hibernate 支持，尽管我们不使用任何特定于 Hibernate 的 API)。
最佳答案
我个人会避免尝试在池中的 JDBC 连接上设置单独的参数。毕竟，池的想法是所有连接都是相同的。因此，虽然你的拦截器想法可行，但我也担心它会多么脆弱。该实现中的任何错误都将是最糟糕的竞争条件。
另一方面，由于您使用的是 Oracle，因此您可能需要查看 EclipseLink。它实现了 JPA2，并得到了 Oracle 的大力资助，因此它支持它们所有奇怪的功能。您可能想考虑使用 'Isolated Client Sessions' 。它看起来支持需要单独 session 设置的虚拟专用数据库。因此，如果您需要更改 session 上下文，这将是一个解决方案。
关于oracle - 在 JPA 连接中设置上下文 — 这安全吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14045219/