@Asynchronous EJB 和休眠连接问题

Posted 2023-02-19

【中文标题】@Asynchronous EJB 和休眠连接问题

【英文标题】：@Asynchronous EJB and hibernate connection issues

【发布时间】：2020-03-02 02:26:02

【问题描述】：

    @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>

Persistence.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> 

【问题讨论】：

@Asynchronous 在哪里？你是故意漏掉的吗？

问题似乎出在您访问帖子中缺少的数据库的部分。

对不起，@Asynchronous 应该在那里，只是忘记输入了

【参考方案1】：

这不是一个完整的答案，因为我无法确定真正的根本原因，但我会在这里写下我的发现和可能的解决方法。

我在 Wildfly 应用程序服务器中遇到过这个问题（在撰写本文时也是一个相当新的版本），并且似乎记得很久以前在 GlassFish 服务器上看到过同样的问题。问题似乎出在 Hibernate 而不是 EJB 容器或 JTA 管理器上，尽管我对此不是 100% 确定的。尽管存在警告和恼人的堆栈跟踪，但代码似乎按照您的期望正确运行。事务被提交并且不会由于错误而回滚，调用似乎在单独的事务中使用它们自己的连接运行，而且我没有注意到某种连接泄漏会导致长时间后出现问题。所以至少在功能上看起来还不错。

这里的主要怀疑是在某种程度上建立连接和事务的范围与关闭它们的范围不同。我不知道是异步调用还是 EJB 的自注入是触发问题的原因，以及其中之一是否足以复制它。我怀疑对@Asynchronous 方法的调用将为实体管理器获取数据库连接并启动事务，这与线程或调用异步方法的其他上下文有某种关联。但是当然，该方法是异步的，实际执行将由 EJB 容器在单独的线程中处理，并且该方法立即返回，如果其返回类型为 void 则不返回任何内容，或者返回 Future 以获得结果。当方法完成时，EJB 容器负责事务提交或回滚并释放连接。 Hibernate 似乎不喜欢在不同的上下文或线程中看到这种情况，因此会出现错误。但是错误发生在事务完成后（因此代码可以工作），并且因为它发生在某个容器管理的线程中，而不是调用者的线程中，所以异常永远不会冒泡到您的代码中。

现在，如果仅此而已，那么异步 EJB 方法可以始终如一地复制此问题。但它似乎没有这样做。 EJB 的自注入似乎也是触发这一点的必要条件。事实上，在 GlassFish 项目中，我不记得使用异步方法，但我确实有一个 EJB 获取它自己类的另一个实例。因此，也许仅此一项就足以获得这种行为。为什么会在这种情况下发生，我还没有弄清楚，但我会在一个可能的解决方案示例之后回到它。

不管是什么原因，我使用的一种似乎可以消除错误的解决方法是在 EJB 类本身中简单地使用@EJB 注入，而不是通过@Resource-注入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 或托管 bean 中使用 @EJB 或 @Inject 注释的字段实际上是一个代理对象，并且在使用该代理时会完成类的实际实例的查找或实例化。那些myStatelessProxy1 和myStatelessProxy2 字段只是代理占位符，一旦在它们上调用方法，MyStatelessBeanA 的实例就会分配给代理，完成自己的注入并获得数据库连接和事务等资源语境。并且该实例又可能具有这两个字段，但它们也是代理，并且如果不使用它们，则不会发生进一步的递归。如果您在注入实例上调用的方法依赖于它自己的注入字段之一，然后又在其上调用执行相同操作的方法，您可能会意外地创建一些无限递归。因为这与同一对象实例中的递归不同，所以它可能不会立即显现出来，编译器或 IDE 可能不会警告您，所以要小心。

应该从 EJB 2.1 API 开始支持这种自注入。奇怪的是，这样做似乎会导致不再抛出 Hibernate 错误。回到我之前提到的关于此的内容，一个可能的原因可能是创建 EJB 代理的位置。在一种情况下，我们要求SessionContext 创建一个实例，这发生在 EJB 的一个方法中。在另一种情况下，我们通过@EJB 注入点获取实例，这将在调用EJB 方法之前完成。这是两种不同的语境。一个在您的代码中，可能具有自己的数据库连接，并且可能在事务中运行。另一个在容器的代码内，在事务边界之外，可能在建立数据库连接之前。现在，这是代理，我们可能希望它们只有在我们使用它们时才会启动，但是谁知道容器在创建代理对象时可能会预先做哪些工作以及传递给它们的内容。也许当前的 Hibernate 版本可以正确处理此问题，但在将异步方法投入混合时仍然会出错。

自注入可能会解决您的问题，但如果您需要动态数量的这些 EJB 实例（这可以在从 SessionContext 获取它们时完成），则不会起作用。但在这种情况下，无论如何代码设计都可能存在问题。一次注入就足够了，因为您可以将那个注入重复用于多个异步方法调用。他们每个人都在各自的线程中运行。他们也有自己的交易。异步方法不能加入其调用者的事务，因为调用者的事务完成的点将不再是它退出其事务边界的时候。它将在未来的“某个时间点”完成。这弄乱了语义。唯一的选择是让调用者在退出其方法后等待，直到它启动的异步调用完成，但这在某些情况下会破坏它们的目的（比如当您不需要返回值时）。如果您必须生成不可预测数量的异步任务，ManagedExecutorService 可能更合适。它是 JEE 7 中引入的 Java EE 并发实用程序的一部分。

最后，另一种解决方案可能是只创建一些额外的帮助 EJB 类，它会注入另一个 EJB 类，然后使用它。划分可能有点人为，因为它只是为了处理容器管理的影响而存在，而不是作为您的要求的直接结果，但它简单有效。与自注入相反，它也很容易推理，并且可以帮助编写测试和使用模拟对象。