java 异步方法的默认 EJB 事务模式?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/4016117/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Default EJB transaction mode for asynchronous methods?
提问by Mike Baranczak
When I have an
@Asynchronous
method in an EJB, and I don't specify the@TransactionAttribute
, then how exactly does the container handle the transaction boundaries? Obviously, it can't use the calling thread's transaction, so what does it do?Same question, but regarding methods that are triggered by the TimerService.
当我
@Asynchronous
在 EJB 中有一个方法时,我没有指定@TransactionAttribute
,那么容器究竟是如何处理事务边界的?显然,它不能使用调用线程的事务,那它有什么作用呢?同样的问题,但关于 TimerService 触发的方法。
EDIT: I think I phrased that poorly. I already know that the default mode is 'REQUIRED'. So it should be safe to assume that those methods will always be called within a transaction. But my question is, what does that transaction's life-cycle look like? Does the container create a new transaction for each call? Or does it re-use the same transaction for all the calls on an asynchronous worker thread? If it's the latter, then when does the transaction get closed?
编辑:我想我说得不好。我已经知道默认模式是“必需”。因此,可以安全地假设这些方法将始终在事务中调用。但我的问题是,该交易的生命周期是什么样的?容器是否为每次调用创建一个新事务?或者它是否对异步工作线程上的所有调用重复使用相同的事务?如果是后者,那么交易什么时候结束?
回答by David Blevins
Similar to an MDB the transaction is started by the container just before your @Asynchronous
, @Schedule
or @Timeout
method (and applicable interceptors) is actually invoked and committed just after the method (and interceptors) completes.
与 MDB 类似,事务由容器在您的@Asynchronous
,@Schedule
或@Timeout
方法(和适用的拦截器)在方法(和拦截器)完成后实际调用和提交之前启动。
As per usual, the transaction propagates to all beans called in said method and all beans those beans call, recursively. Of course other beans invoked are welcome to change the transaction semantics of their method call via specifying other @TransactionAttribute
settings (say REQUIRES_NEW
, or NOT_SUPPORTED
).
按照惯例,事务递归地传播到所述方法中调用的所有 bean 和这些 bean 调用的所有 bean。当然,欢迎其他调用的 bean 通过指定其他@TransactionAttribute
设置(例如REQUIRES_NEW
,或NOT_SUPPORTED
)来更改其方法调用的事务语义。
Side note, transactions are never propagated to beans with @TransactionManagement(BEAN)
. The container will alwayssuspend any transaction in progress before invoking a method on a Bean-Managed Transaction bean.
旁注,事务永远不会传播到带有@TransactionManagement(BEAN)
. 在调用 Bean-Managed Transaction bean 上的方法之前,容器将始终挂起任何正在进行的事务。
回答by Przemys?aw Pelczar
From EJB 3.1 spec.
来自 EJB 3.1 规范。
4.5.3 Transactions
Client transaction context does not propagate with an asynchronous method invocation. From the Bean Developer's view, there is never a transaction context flowing in from the client. This means, for example, that the semantics of the REQUIRED transaction attribute on an asynchronous method are exactly the same as REQUIRES_NEW.
4.5.3 交易
客户端事务上下文不与异步方法调用一起传播。从 Bean 开发人员的角度来看,从来没有从客户端流入的事务上下文。这意味着,例如,异步方法上的 REQUIRED 事务属性的语义与 REQUIRES_NEW 完全相同。