EJB 3.x onMessage() 与 @Timeout 事务上下文
在 EJB 3.x 中，对于 MDB 的 onMessage() 方法以及 SLSB 和 MDB 的 @Timeout 方法，没有事务传播。也就是说，没有客户端来执行该方法，因此不可能传播事务。
当使用容器管理的事务时，我希望这两种情况接受相同的javax.ejb.TransactionAttributeType。然而，他们没有。
对于 onMessage() 方法，REQUIRED 和 NOT_SUPPORTED 是可接受的事务属性，而对于 @Timeout 方法，REQUIRED、REQUIRES_NEW 和 NOT_SUPPORTED 是可接受的事务属性。
特别是，对于 @Timeout 方法，规范中指出（第 18.2.8 段）：
请注意，容器必须启动 如果需要，则新交易 （必填）交易属性为 用过的。本次交易属性值 是允许的，因此规范 超时的事务属性 回调方法可以默认。
如果我正确地理解了这一点，通常应该在此处使用 REQUIRES_NEW，但是因为 REQUIRED 是 EJB 的默认值，所以它也允许用于 @Timeout 方法，使其具有与 REQUIRES_NEW 相同的语义，因为有交易不可能被传播。
疑问：
- 我的理解正确吗？
- 为什么 REQUIRES_NEW 在
onMessage()中也不被接受？在交易方面有什么不同吗？
更新： 对于支持 REQUIRES_NEW 的其他情况也是如此：@Asynchronous 和 @PostConstruct/@PreDestroy 方法。
in EJB 3.x for both the onMessage() method of MDBs and the @Timeout method of SLSBs and MDBs there is no transaction propagation. That is, there is no client for the execution of the method, so a transaction can't be possibly propagated.
When using Container-managed transactions, I would expect the two cases to accept the same javax.ejb.TransactionAttributeType. However, they don't.
For the onMessage() method, REQUIRED and NOT_SUPPORTED are the acceptable transaction attributes, whereas for @Timeout methods REQUIRED, REQUIRES_NEW and NOT_SUPPORTED.
In particular, for the @Timeout methods the spec says (par. 18.2.8):
Note that the container must start a
new transaction if the REQUIRED
(Required) transaction attribute is
used. This transaction attribute value
is allowed so that specification of a
transaction attribute for the timeout
callback method can be defaulted.
If I get this correctly, normally REQUIRES_NEW should be used here, but because REQUIRED is the default for an EJB, it is also allowed for @Timeout methods, giving it the same semantic as REQUIRES_NEW, since there is no possibility of a transaction to be propagated.
Questions:
- Is my understanding correct?
- Why isn't REQUIRES_NEW acceptable also in
onMessage()? Is it different somehow in respect of transactions?
UPDATE:
The same goes for other cases where REQUIRES_NEW is supported: @Asynchronous and @PostConstruct/@PreDestroy methods.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，你的理解是正确的。
在我看来，@Timeout 指定 REQUIRES_NEW 很奇怪。该规范基本上要求容器在与超时方法相同的事务中更新持久计时器数据库。这实际上与事务性 JCA 消息传递没有任何不同，只是在 JCA 场景中更明显的是外部组件正在处理事务。我想您可能会争辩说没有 JavaEE 组件驱动 @Timeout 方法，但在我看来，最好禁止两者都使用 REQUIRES_NEW。无论如何，这种不一致很奇怪，因此也许 MDB 将在规范的更高版本中更新以允许 REQUIRES_NEW。
Yes, your understanding is correct.
In my opinion, @Timeout is odd for specifying REQUIRES_NEW. The spec basically requires that the container update the persistent timer database within the same transaction as the timeout method. This isn't really any different than transactional JCA message delivery, except that it's more apparent in the JCA scenario that an external component is handling the transaction. I suppose you could argue that there is no JavaEE component driving the @Timeout method, but in my opinion, it would have been better to disallow REQUIRES_NEW for both. Regardless, the inconsistency is odd, so perhaps MDB will be updated in a later version of the spec to allow REQUIRES_NEW.