multithreading - @Asynchronous EJB 和休眠连接问题
问题描述
@Stateless
public class MyStatelessBeanA {
@Resource
private SessionContext sessionCtx;
public byte[] methodA(){
MyStatelessBeanA myStatelessProxy1 = this.sessionCtx.getBusinessObject(MyStatelessBeanA.class);
MyStatelessBeanA myStatelessProxy2 = this.sessionCtx.getBusinessObject(MyStatelessBeanA.class);
Future<byte[]> proxy1Future = myStatelessProxy1.asynchMethod();
Future<byte[]> proxy2Future = myStatelessProxy2.asynchMethod();
byte[] firstArray = proxy1Future.get();
byte[] secondArray = proxy2Future.get();
return ...
}
@Asynchronous
public Future<byte[]> asynchMethod(){
byte[] byteArray = ...
...do something including select from various table...
return new AsynchResult<byte[]>(byteArray);
}
基本上我想做的是asynchMethod()从两个代理对象并行调用两次。
问题？
2019-11-05 17:20:23,354 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (EJB default - 3) SQL Error: 0, SQLState: null
2019-11-05 17:20:23,354 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (EJB default - 3) IJ031041: Connection handle has been closed and is unusable
2019-11-05 17:20:23,354 INFO [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (EJB default - 2) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@69ebfad0
at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408)
at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:617)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:562)
at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298)
at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256)
at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.closeConnection(DatasourceConnectionProviderImpl.java:127)
at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.releaseConnection(AbstractSessionImpl.java:397)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterStatement(LogicalConnectionManagedImpl.java:125)
at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterStatementExecution(JdbcCoordinatorImpl.java:281)
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:145)
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86)
at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:167)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3956)
at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:508)
at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:478)
at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219)
at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:116)
at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89)
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129)
at org.hibernate.internal.SessionImpl.immediateLoad(SessionImpl.java:997)
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:157)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:266)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:68)
对 asynchMethod() 的两个调用被正确分配给两个不同的线程：
2019-11-05 17:20:22,566 INFO [**.*******.*******.*******.MyStatelessBeanA] (EJB default - 2) method=asynchMethod START
2019-11-05 17:20:22,655 INFO [**.*******.*******.*******.MyStatelessBeanA] (EJB default - 3) method=asynchMethod START
是否有可能以某种方式关闭另一个代理对象的连接？我不知道是否有足够的信息来猜测问题的正确解决方案，但我正在寻找一切可能的东西（CachedConnectionManagerImpl 源代码，TxConnectionListener 源代码），但似乎超出了我的技能。
如果有人可以提供帮助或提供一些提示，因为我完全坚持这一点。
谢谢，戴维德
添加的可能有用的信息
Standalone.xml 休眠部分
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<local-cache name="entity">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="timestamps"/>
</cache-container>
持久性.xml
<?xml version="1.0" encoding="UTF-8" ?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="***" transaction-type="RESOURCE_LOCAL">
<jar-file>file:./target/test-classes</jar-file>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="hibernate.archive.autodetection" value="class,hbm" />
<property name="hibernate.connection.url" value="${dbunit.connectionUrl}" />
<property name="hibernate.connection.driver_class" value="${dbunit.driverClass}" />
<property name="hibernate.dialect" value="${dbunit.jpa-dialect}" />
<property name="hibernate.connection.username" value="${dbunit.username}" />
<property name="hibernate.connection.password" value="${dbunit.password}" />
<property name="javax.persistence.validation.mode" value="NONE" />
<property name="hibernate.show_sql" value="true" />
</properties>
</persistence-unit>
</persistence>
解决方案
这不是一个完整的答案，因为我无法确定真正的根本原因，但我会在这里写下我发现的内容和可能的修复方法。
我在 Wildfly 应用程序服务器（在撰写本文时也是一个相当新的版本）中遇到了这个问题，并且似乎记得很久以前在 GlassFish 服务器上看到过同样的问题。问题似乎出在 Hibernate 而不是 EJB 容器或 JTA 管理器上，尽管我对此不是 100% 确定的。尽管存在警告和恼人的堆栈跟踪，但代码似乎按照您的期望正确运行。事务被提交并且不会由于错误而回滚，调用似乎在单独的事务中使用它们自己的连接运行，我没有注意到某种连接泄漏会导致长时间后出现问题。所以至少在功能上看起来还不错。
这里的主要怀疑是，以某种方式建立连接和事务的范围与关闭它们的范围不同。我不知道是异步调用还是 EJB 的自注入是触发问题的原因，以及其中之一是否足以复制它。我怀疑对该@Asynchronous方法的调用将为实体管理器获取数据库连接并启动事务，这与线程或调用异步方法的其他上下文有某种关联。但是当然，该方法是异步的，实际执行将由 EJB 容器在单独的线程中处理，并且该方法立即返回，如果其返回类型为 void 则不返回任何内容或返回Future以获得结果。当方法完成时，EJB 容器负责事务提交或回滚并释放连接。Hibernate 似乎不喜欢在不同的上下文或线程中看到这种情况，因此会出现错误。但是错误发生在事务完成后（因此代码可以工作），并且因为它发生在某个容器管理的线程中，而不是调用者的线程中，所以异常永远不会冒泡到您的代码中。
现在，如果仅此而已，那么异步 EJB 方法可以始终如一地复制此问题。但它似乎没有这样做。EJB 的自注入似乎也是触发这一点的必要条件。事实上，在 GlassFish 项目中，我不记得使用异步方法，但我确实有一个 EJB 获取它自己类的另一个实例。因此，也许仅此一项就足以获得这种行为。为什么会在这种情况下发生是我还没有弄清楚的事情，但我会在一个可能的解决方案示例之后回到它。
不管是什么原因，我使用的一种似乎可以消除错误的解决方法是简单地@EJB在 EJB 类本身中使用注入，而不是通过@Resource-injected SessionContext。所以你的代码可以重写如下：
@Stateless
public class MyStatelessBeanA {
@EJB
private MyStatelessBeanA myStatelessProxy1;
@EJB
private MyStatelessBeanA myStatelessProxy2;
public byte[] methodA(){
Future<byte[]> proxy1Future = myStatelessProxy1.asynchMethod();
Future<byte[]> proxy2Future = myStatelessProxy2.asynchMethod();
byte[] firstArray = proxy1Future.get();
byte[] secondArray = proxy2Future.get();
return ...
}
@Asynchronous
public Future<byte[]> asynchMethod(){
byte[] byteArray = ...
...do something including select from various table...
return new AsynchResult<byte[]>(byteArray);
}
这可能看起来有点可怕，因为感觉它会导致注入的无限递归。但这不会发生。请记住，使用@EJB或@Inject在某些 EJB 或托管 bean 中注释的字段实际上是代理对象，并且在使用该代理时完成了类的实际实例的查找或实例化。这些myStatelessProxy1和myStatelessProxy2字段只是代理占位符，一旦在它们上调用方法，MyStatelessBeanA分配给代理，完成自己的注入，并获得数据库连接和事务上下文等资源。并且该实例又可能具有这两个字段，但它们也是代理，并且如果不使用它们，则不会发生进一步的递归。如果您在注入实例上调用的方法依赖于它自己的注入字段之一，然后又在其上调用执行相同操作的方法，您可能会意外地创建一些无限递归。因为这与同一对象实例中的递归不同，所以它可能不会立即显现出来，编译器或 IDE 可能不会警告您，所以要小心。
从 EJB 2.1 API 开始，应该支持这种自注入。奇怪的是，这样做似乎会导致不再抛出 Hibernate 错误。回到我之前提到的关于此的内容，一个可能的原因可能是创建 EJB 代理的位置。在一种情况下，我们要求 aSessionContext创建一个实例，这发生在 EJB 的一个方法中。在另一种情况下，我们通过@EJB注入点，这将在调用 EJB 方法之前完成。这是两种不同的语境。一个在您的代码中，可能具有自己的数据库连接，并且可能在事务中运行。另一个在容器的代码内，在事务边界之外，可能在建立数据库连接之前。现在，这是代理，我们可能希望它们只有在我们使用它们时才会启动，但是谁知道容器在创建代理对象时可能会预先做哪些工作以及传递给它们的内容。也许当前的 Hibernate 版本可以正确处理此问题，但在将异步方法投入混合时仍然会出错。
自我注入可能会解决您的问题，但如果您需要动态数量的这些 EJB 实例（这可以在从SessionContext. 但在这种情况下，无论如何代码设计都可能存在问题。一次注入就足够了，因为您可以将那个注入重复用于多个异步方法调用。他们每个人都在各自的线程中运行。他们也有自己的交易。异步方法不能加入其调用者的事务，因为调用者的事务完成的点将不再是它退出其事务边界的时候。它将在未来的“某个时间点”完成。这弄乱了语义。唯一的选择是让调用者在退出其方法后等待，直到它启动的异步调用完成，但这在某些情况下会破坏它们的目的（比如当您不需要返回值时）。ManagedExecutorService可能更合适。它是 JEE 7 中引入的 Java EE 并发实用程序的一部分。
最后，另一种解决方案可能是只创建一些额外的帮助 EJB 类，将另一个注入然后使用它。划分可能有点人为，因为它只是为了处理容器管理的影响而存在，而不是作为您的要求的直接结果，但它简单有效。与自注入相反，它也很容易推理，并且可以帮助编写测试和使用模拟对象。
推荐阅读
- gradle - 在 packageRunBuild Segmentation Fault 上 Gradle 构建失败
- python - C++ python模块（基于Pybind11）导入报错：ModuleNotFoundError
- javascript - 如何正确创建班级成员？
- c# - 如何在 .netcore-3.0 中测试标头属性？
- php - 为什么边缘不缓存图像
- cakephp - 如何获取包含子句以在 CakePHP 中生成正确的代码
- r - 如何模拟一个 100 人的班级？
- javascript - 如何使用具有不透明响应的 API？
- bash - 尝试运行 Bash 程序会导致“权限被拒绝”错误消息
- java - Spring Cloud Config 无法获取正确的值