Postgres READ_COMMITED隔离级别下唯一约束违例触发时机问询

核心结论 #

在PostgreSQL的READ_COMMITTED隔离级别下，确实存在唯一约束违例在事务提交阶段才抛出的可能性，这种情况会导致你代码中“邮件已发送但实体未持久化”的不一致问题。

原因分析 #

PostgreSQL对唯一约束的检查分为两个阶段：

1. 执行INSERT/UPDATE等DML语句时，会基于当前已提交的数据进行约束检查，此时如果没有冲突，语句会执行成功并持有对应行的锁。
2. 当事务提交时，PostgreSQL会再次验证唯一约束——如果在当前事务执行DML之后、提交之前，有其他事务提交了包含相同唯一键的数据，当前事务提交时就会触发唯一约束违例，抛出异常。

举个典型场景：

• 事务A执行INSERT插入唯一键为X的实体，此时无冲突，语句执行成功。
• 事务B同时执行INSERT插入唯一键为X的实体，由于READ_COMMITTED隔离级别下每个语句只能看到已提交的数据，此时事务A的变更还未提交，事务B的INSERT语句也执行成功。
• 事务A先提交，事务B随后提交时，PostgreSQL发现唯一键冲突，抛出约束违例，事务B的变更被回滚，但如果事务B在INSERT后已经发送了邮件，就会出现邮件已发但数据未持久化的问题。

解决方案 #

针对这个问题，有几种可靠的处理方式：

1. 主动触发Flush提前检查约束 #

在执行持久化操作后，主动调用ORM的flush()方法（比如JPA的entityManager.flush()），强制将SQL语句发送到数据库执行并完成约束检查。这样如果存在唯一约束冲突，异常会在发邮件之前就抛出，避免无效的邮件发送。

调整后的代码示例：

@Transactional(isolation = READ_COMMITTED)
public void persistUniqueAndSendEmail() {
    SomeEntity e = // 构造实体
    entityManager.persist(e);
    try {
        // 主动触发flush，提前检查约束
        entityManager.flush();
        // 只有flush成功（无约束违例）才发送邮件
        sendNotificationEmail();
    } catch (PersistenceException ex) {
        // 处理约束违例异常
        throw ex;
    }
}

2. 将邮件发送逻辑放在事务提交之后 #

不要在事务内部发送邮件，而是确保事务提交成功后再执行邮件发送操作。可以通过事务同步器（比如Spring的TransactionSynchronizationManager）来实现：

@Transactional(isolation = READ_COMMITTED)
public void persistUniqueAndSendEmail() {
    SomeEntity e = // 构造实体
    entityManager.persist(e);
    
    // 注册事务提交成功后的回调
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
        @Override
        public void afterCommit() {
            // 事务提交成功后才发送邮件
            sendNotificationEmail();
        }
    });
}

3. 加锁查询提前拦截冲突 #

可以在执行持久化前，先通过加锁的SELECT语句检查唯一键是否存在，避免竞态条件：

@Transactional(isolation = READ_COMMITTED)
public void persistUniqueAndSendEmail() {
    // 加悲观写锁查询唯一键是否存在
    SomeEntity existing = entityManager.createQuery(
        "SELECT e FROM SomeEntity e WHERE e.uniqueKey = :key", SomeEntity.class)
        .setParameter("key", e.getUniqueKey())
        .setLockMode(LockModeType.PESSIMISTIC_WRITE)
        .getResultStream()
        .findFirst()
        .orElse(null);
    
    if (existing != null) {
        // 处理已存在的情况
        throw new DuplicateKeyException("唯一键已存在");
    }
    
    SomeEntity e = // 构造实体
    entityManager.persist(e);
    sendNotificationEmail();
}

这种方式可以提前拦截大部分冲突，但性能会略有下降，适合并发量不是极高的场景。

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