Java @TransactionAttribute（TransactionAttributeType.REQUIRES_NEW）为提交事务占用了太多时间

在我们的应用程序中，我们为我们的业务逻辑创建了新的事务。因此，我们首先将不支持的标记到我们的包装器方法，然后该包装器方法调用实际的业务逻辑方法，该方法上有需要新的。现在的问题是，当调用返回到包装器方法时，时间差是几乎占整个API时间的40%到50%。以下是我的代码片段：

A.java B.java 因此，假设API花费的时间为1秒，那么返回ob:之前的时间与方法B调用之后的时间之间的差值为400到500毫秒，几乎是总时间的40%到50%。两个sysout操作之间没有其他逻辑

那么，这背后的原因是什么

EJB框架为您提供的幕后逻辑，即提交事务，这可能代价高昂。它是在方法返回之后完成的

请理解，由于业务方法中的事务性更改实际上不会执行任何数据库提交，因此您的sysout可能实际上是正确的，但真正繁重的工作是在方法返回时完成的

public Object B() {
    //start tx
    doSomeDatabaseChange(); //quite fast

    return obj;
    // commit or rollback tx, may take time
} 

---

对

B（）

的调用是本地调用，甚至不会启动新事务。请提供可编译的代码。这不会编译。这是原始代码的示例代码。我不能提供太大的整个原始代码。但这里我试图解释原始代码的流程。方法B（）是通过依赖项注入调用的。像@IgnoreDependency@EJB（mappedName=“JNDINAME”）。即使是所有的方法调用，无论是从类A到B还是从B到B的方法调用。它们都使用依赖项注入。感谢您的回复，我们非常感谢。是的，您是对的，总时间中包含了DB提交时间。但在我们的特殊情况下，我发现在一个地方我们无法关闭JDBC连接。因此，既然我们使用jboss作为一个事务管理器，在提交jboss之后，它会自动为我们关闭打开的连接。这是最长的时间。在解决了这个问题后，时间会减少。这大约占总时间的10%到20%。

@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public Object BWrapper(){

     B();
     sysout("Time just after method B call:"+System.currentTimeMillis());
     return ob;
}

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public Object B(){

    sysout("Time before returning ob:"+System.currentTimeMillis());
    return ob;
} 

public Object B() {
    //start tx
    doSomeDatabaseChange(); //quite fast

    return obj;
    // commit or rollback tx, may take time
}