一、事务属性配置的两种核心方式

在企业级JavaBean（EJB）框架中，事务属性的配置是确保业务逻辑一致性的关键环节。开发者可通过两种主要方式定义事务边界：

1.1 注解驱动配置

通过javax.ejb.TransactionAttribute注解可直接在Bean类或方法上声明事务属性，其核心参数为TransactionAttributeType枚举值，包含六种标准事务行为：

@Stateless
public class OrderService {
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void createOrder(Order order) {
        // 业务逻辑
    }
}

方法级注解具有最高优先级，可覆盖类级注解配置。例如当类标记为SUPPORTS而方法标记为REQUIRED时，实际执行将采用REQUIRED策略。

1.2 XML部署描述符配置

在ejb-jar.xml文件中通过container-transaction元素进行全局配置：

<enterprise-beans>
    <session>
        <ejb-name>OrderService</ejb-name>
    </session>
</enterprise-beans>
<assembly-descriptor>
    <container-transaction>
        <method>
            <ejb-name>OrderService</ejb-name>
            <method-name>*</method-name>
        </method>
        <trans-attribute>Required</trans-attribute>
    </container-transaction>
</assembly-descriptor>

XML配置具有最高优先级，可覆盖所有注解配置。这种分层配置机制为不同开发阶段（编码期/部署期）提供了灵活的事务管理手段。

二、事务管理类型深度解析

EJB支持两种根本不同的事务管理模式，其适用场景与技术特性存在显著差异：

2.1 容器管理事务（CMT）

作为推荐模式，CMT通过声明式编程简化事务控制：

• 适用范围：所有实体Bean及事务类型设置为Container的会话Bean
• 标准属性：
  • NOT_SUPPORTED：非事务环境执行
  • SUPPORTS：继承调用方事务状态
  • REQUIRED：必须存在事务（无则新建）
  • REQUIRES_NEW：总是新建事务
  • MANDATORY：必须存在事务（无则抛异常）
  • NEVER：必须在无事务环境执行

典型应用场景：

@Stateless
public class PaymentService {
    @TransactionAttribute(REQUIRED)
    public void processPayment(Payment payment) {
        // 自动参与事务管理
    }
}

2.2 Bean管理事务（BMT）

适用于需要精细控制事务边界的复杂场景：

• 适用范围：事务类型设置为Bean的会话Bean

• 核心接口：通过javax.transaction.UserTransaction手动控制

  @Stateless
  @TransactionManagement(TransactionManagementType.BEAN)
  public class ComplexOrderService {
    @Resource
    private UserTransaction userTransaction;
    public void executeComplexOrder() throws Exception {
        userTransaction.begin();
        try {
            // 业务逻辑
            userTransaction.commit();
        } catch (Exception e) {
            userTransaction.rollback();
            throw e;
        }
    }
  }

  BMT模式要求开发者自行处理事务边界、异常恢复等复杂逻辑，适用于需要跨多个资源管理器或实现自定义事务策略的场景。

三、特殊场景的事务处理

3.1 生命周期回调方法

@PostConstruct和@PreDestroy等回调方法仅支持三种事务属性：

• REQUIRED：继承当前事务（无则新建）
• REQUIRES_NEW：强制新建事务
• NOT_SUPPORTED：非事务环境执行

典型配置示例：

@Stateless
public class LifecycleBean {
    @PostConstruct
    @TransactionAttribute(REQUIRES_NEW)
    private void init() {
        // 独立事务初始化
    }
}

3.2 有状态会话Bean的特殊处理

在有状态Bean中，标记为TX_NOT_SUPPORTED或TX_NEVER的方法可在结束时触发检查点操作：

@Stateful
public class CheckpointBean {
    @TransactionAttribute(NOT_SUPPORTED)
    public void performCheckpoint() {
        // 方法结束时自动执行检查点
    }
}

这种机制特别适用于需要持久化中间状态的长时间运行事务场景。

四、最佳实践与性能优化

4.1 配置优先级策略

1. 方法级注解 > 类级注解
2. XML配置 > 所有注解配置
   建议采用”默认注解+特殊XML覆盖”的混合模式，在保持代码可读性的同时保留部署期调整灵活性。

4.2 事务属性选择指南

场景	推荐属性	避免属性
查询操作	NOT_SUPPORTED	REQUIRES_NEW
创建/更新操作	REQUIRED	NEVER
异步处理	REQUIRES_NEW	MANDATORY
批量操作	REQUIRED	SUPPORT

4.3 异常处理模式

• 系统异常（RuntimeException）：自动触发事务回滚
• 应用异常（Checked Exception）：默认提交事务，需通过@ApplicationException(rollback=true)显式配置回滚行为

五、进阶应用场景

5.1 分布式事务协调

在跨多个EJB容器的分布式场景中，推荐使用REQUIRES_NEW属性确保每个操作在独立事务中执行，配合XA资源实现两阶段提交。

5.2 与消息队列集成

当EJB方法需要与消息中间件交互时，建议采用REQUIRED属性保证消息发送与业务操作的事务一致性：

@Stateless
public class MessageProducer {
    @Resource
    private QueueConnectionFactory queueFactory;
    @TransactionAttribute(REQUIRED)
    public void sendWithTransaction(String message) {
        // 业务逻辑与消息发送在统一事务中
    }
}

5.3 微服务架构适配

在拆分为微服务的EJB应用中，可通过NOT_SUPPORTED属性降低事务开销，配合最终一致性模式实现跨服务数据同步。

结语

EJB事务属性配置体系通过声明式编程与灵活的管理模式，为构建企业级事务应用提供了强大支撑。开发者需深入理解不同事务类型的适用场景，合理运用注解与XML配置的优先级机制，结合生命周期回调和有状态Bean的特殊处理能力，才能设计出既满足业务需求又具备高性能的事务处理系统。在实际开发中，建议通过性能测试验证不同事务策略的实际开销，根据具体场景选择最优配置方案。