Spring Integration JDBC分布式锁多线程事务冲突及正确用法咨询

问题背景 #

通过以下步骤复现问题：

1. 启动PostgreSQL容器：

docker run -e POSTGRES_USER=localtest -e POSTGRES_PASSWORD=localtest -e POSTGRES_DB=orders -p 5432:5432 -d postgres:15.3

2. 运行示例代码：控制器通过并行流启动3个线程，分别调用带@Transactional注解的testLock方法，每个线程使用独立事务、不同锁Key尝试获取JDBC分布式锁。

现象：

• 保留pretendToDoWork方法时，3个线程均可正常获取并释放锁；
• 注释该方法后，仅1个线程成功，其余抛出Unable to commit against JDBC Connection异常。

1. 为何移除pretendToDoWork后出现冲突？ #

核心原因是短事务下的连接状态竞态问题：
当没有pretendToDoWork时，testLock方法执行时间极短，Spring事务管理器完成事务提交后，还没来得及完全恢复JDBC连接的状态（比如将autoCommit恢复为默认值），连接就被放回连接池。后续线程复用该连接时，连接的事务状态处于未完全清理的状态，此时尝试提交新事务就会触发Unable to commit against JDBC Connection异常。

而pretendToDoWork的存在让事务执行时间足够长，Spring有充足时间完成事务提交和连接状态重置，避免了连接复用的竞态冲突。另外，短事务下PostgreSQL锁释放与事务提交的同步延迟，也会加剧这种冲突，但核心诱因还是连接池的状态复用问题。

2. 多线程多事务场景下，正确使用JDBC分布式锁的方式？ #

遵循以下核心原则：

• 锁操作与业务事务完全分离：不要将锁的获取/释放放在业务事务中，锁操作应使用独立的微型事务，避免业务事务的提交、回滚或延迟影响锁的生命周期。
• 原子性获取锁：使用PostgreSQL支持的原子锁语法，比如SELECT ... FOR UPDATE SKIP LOCKED实现非阻塞锁，或INSERT ... ON CONFLICT实现基于唯一键的乐观锁式分布式锁，确保锁的获取是原子操作，不会出现竞态。
• 可靠释放锁：用try-finally块包裹锁操作，确保即使业务抛出异常也能释放锁；同时设置锁的过期时间，配合定时任务清理失效锁，避免死锁。
• 避免连接复用干扰：可以为锁操作分配独立的JDBC连接池，或在锁操作完成后强制重置连接状态，防止连接的事务状态残留影响后续操作。

3. Problem2GoodFixService是否为合规实现方案？ #

是的，这是符合分布式锁最佳实践的合规方案：

• 缩小事务范围：将锁操作限制在独立的小事务中，锁的获取和释放不依赖于业务事务的生命周期，避免了业务事务延迟或回滚导致的锁异常。
• 分离锁与业务操作：锁操作和业务SQL分别在独立事务中执行，两者状态互不干扰，既保证了锁的原子性，也避免了业务操作对锁状态的影响。
  这种设计完全规避了原方案中事务与锁绑定、连接状态竞态的问题，是多线程多事务场景下JDBC分布式锁的合理实现方式。

内容的提问来源于stack exchange，提问作者Cui Pengfei 崔鹏飞