@Transactional 行为异常：Teams通知队列事务问题咨询

① 关于REQUIRES_NEW事务的执行机制 #

是的，在Spring中使用@Transactional(propagation = Propagation.REQUIRES_NEW)时，若当前存在活跃的原事务，原事务会被暂停挂起，新事务会独立创建并执行。当新事务完成提交或回滚后，原事务才会恢复继续执行。

② 场景正确处理方式及当前方案分析 #

当前方案的问题 #

1. 同类方法标记REQUIRES_NEW：虽然功能正常，但代码质量检查提示不兼容，本质是Spring事务基于动态代理实现，同类内部方法调用不会触发代理逻辑，实际REQUIRES_NEW的事务边界可能不符合预期（你这里功能正常可能是巧合，比如用了AspectJ织入，但代码规范不允许这种写法）。
2. 移至Helper类后出现行锁：原因是原事务在读取消息时使用了悲观锁（如select ... for update），原事务被挂起期间锁依然持有，新事务提交后原事务未及时结束，导致该行被长期锁定，其他实例无法处理。

正确处理方式 #

1. 优化数据库锁机制

读取消息时，使用带跳过锁的悲观锁（数据库需支持，如MySQL 8.0+、PostgreSQL），避免实例间阻塞：

SELECT * FROM notification_queue 
WHERE status = 'PENDING' 
LIMIT 1 
FOR UPDATE SKIP LOCKED;

SKIP LOCKED会让当前实例跳过已被其他实例锁定的行，直接获取下一条可处理的消息，不会等待锁释放。

2. 合理拆分事务边界

• 原事务：负责读取消息（加锁）、调用MSTeams通知接口。若调用失败，先触发独立事务记录重试信息，再抛出异常让原事务回滚（消息回到待处理状态）。
• 重试记录方法：必须放在独立Bean（如TeamsNotificationHelper）中，标记@Transactional(propagation = Propagation.REQUIRES_NEW)，确保与原事务隔离。示例代码：

// 调度类（原事务）
@Service
public class NotificationScheduler {
    @Autowired
    private TeamsNotificationHelper helper;
    @Autowired
    private NotificationQueueDao dao;

    @Transactional
    public void processNotification() {
        NotificationQueue msg = dao.getPendingMessageWithLock(); // 带SKIP LOCKED的查询
        try {
            // 调用MSTeams通知接口
            sendToTeams(msg);
            // 处理成功，更新状态为已完成
            dao.updateStatus(msg.getId(), "COMPLETED");
        } catch (Exception e) {
            // 先记录重试信息（独立事务）
            helper.recordRetryInfo(msg.getId(), e.getMessage());
            // 抛出异常触发原事务回滚，消息状态回到PENDING
            throw new NotificationProcessException("处理失败，触发回滚", e);
        }
    }
}

// Helper类（独立事务）
@Service
public class TeamsNotificationHelper {
    @Autowired
    private RetryRecordDao retryDao;

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void recordRetryInfo(Long msgId, String errorMsg) {
        RetryRecord record = new RetryRecord();
        record.setMsgId(msgId);
        record.setErrorMsg(errorMsg);
        record.setRetryCount(1);
        retryDao.save(record);
    }
}

3. 额外优化建议

• 给远程调用（MSTeams接口）设置合理超时，避免原事务长时间持有锁。
• 若业务允许，可引入分布式消息队列（如RabbitMQ）替代数据库表做通知队列，天然支持重试、负载均衡，避免数据库锁问题。

内容的提问来源于stack exchange，提问作者SemJax