jakarta-ee - 为什么带有 bean 管理事务的 EJB bean 充当 "transaction barrier"?

标签 jakarta-ee transactions ejb bean-managed-transactions

引自 EJB 3.1 specification :

13.6.1 Bean-Managed Transaction Demarcation

The container must manage client invocations to an enterprise bean instance with bean-managed transaction demarcation as follows. When a client invokes a business method via one of the enterprise bean’s client views, the container suspends any transaction that may be associated with the client request.



另一方面,来自独立客户端或另一个 EJB 的事务使用容器管理的事务传播到 bean 中。从 CMT 的角度来看,使用 CMT 的 bean 似乎有一个额外的重要特性(事务传播)。

对使用 BMT 的 bean 施加这种限制(“事务屏障”)的原因是什么?

相关问题:
  • JPA transaction rollback fails with call to stateless bean
  • How does UserTransaction propagate?
  • How to propagate a client-side UserTransaction into a stateless session bean using BMT (报价已从那里复制)
  • 最佳答案

    我的“猜测”是这样的

    容器“看到”您已将 bean 标记为 BMT

    所以在某些时候你可能会使用 UserTransaction 对象及其开始/提交/回滚等方法

    而且由于 weblogic/oracle 等不支持真正的嵌套事务..
    容器不得不暂停当前事务以支持新事务

    在 CMT 的情况下 - 由于您使用 Requires 或 RequiredNew - 容器“知道”您的意图并选择继续相同的事务,或相应地暂停并开始新的事务

    关于jakarta-ee - 为什么带有 bean 管理事务的 EJB bean 充当 "transaction barrier"?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17898154/

    相关文章:

    c# - C#SQLite事务-此用法有效吗?

    jsp - 三层架构问题

    java - Struts <bean :write> tags

    jakarta-ee - 启动依赖于不同模块中的单例 EJB,但在同一个 ear 文件中

    java - 根据 birt 报告中的 if 条件显示数据

    entity-framework - IDomainService 中的 ABP EF Core 多个 DbContext 访问抛出事务错误

    java - 为什么 JMS MessageListener 中使用的实体管理器不参与 JTA 事务?

    java - 在 EJB 中打开文件

    java - 当客户端 VM 突然终止时,有状态 EJB 不会被钝化

    java - native 查询产生 MySQL 语法错误和意外结果