在我们的应用程序中,我们为业务逻辑创建了新的Transaction。为此,我们首先将 NOT_SUPPORTED 标记为我们的包装器方法,然后该包装器方法调用具有 REQUIRES_NEW <的实际业务逻辑方法现在问题是,当调用回到包装器方法时,时间的差异几乎是整个API时间的40%到50%。以下是我的代码片段:
public Object A(){
long stime = System.currentTimeMillis()
b.BWrapper();
sysout("Time taken by API :"+System.currentTimeMillis() - stime);
}
@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;
}
所以,假设如果 API花费的时间:1秒那么返回ob之前的时间:和方法B调用之后的时间之间的差异:会像 400到500毫秒,这几乎是总时间的40%到50%。并且两个sysout操作之间没有其他逻辑。
那背后的原因是什么?
答案 0 :(得分:0)
EJB框架为您做幕后的是逻辑,即提交事务,这可能代价高昂。它是在方法返回后完成的。
明白,因为业务方法内部的事务性更改并没有真正进行任何数据库提交,所以你的sysout实际上可能是正确的,但真正繁重的工作就在那之后,在方法返回时完成。
public Object B() {
//start tx
doSomeDatabaseChange(); //quite fast
return obj;
// commit or rollback tx, may take time
}