PostgreSQL只读事务执行nextval()异常排查求助

首先，这个问题的核心矛盾是：标记为只读的事务中意外执行了写操作（调用nextval()，通常对应实体持久化），而且因为使用pgbouncer连接池，连接复用大概率是关键诱因。结合你的Spring + Hibernate + pgbouncer session模式环境，我整理了以下逐步排查的方向：

1. 先确认Spring事务注解的实际生效情况 #

虽然你提到已经正确使用@Transactional，但偶发问题往往和代理失效或传播行为冲突有关：

• 检查同一类内部方法调用：如果一个标记readOnly=true的方法，直接调用了本类中带写操作的方法（比如persist()），Spring代理不会拦截内部调用，导致写操作被嵌套在只读事务中执行。这种情况可以通过把写方法抽成独立Bean，或者用AopContext.currentProxy()绕开代理问题。
• 核对事务传播属性：比如某个写方法的propagation设置为REQUIRED，如果它被一个只读事务调用，会直接复用当前只读事务，导致写操作失败。可以检查写方法的传播属性是否设置为REQUIRES_NEW（必要时开启新事务）。
• 验证只读事务的实际生效：在日志中加入事务状态打印，比如通过Spring的TransactionSynchronizationManager.isCurrentTransactionReadOnly()，确认触发异常时确实处于只读事务上下文。

2. 排查pgbouncer连接复用的遗留状态问题 #

你的pgbouncer配置是pool_mode=session + server_reset_query=DISCARD ALL，但DISCARD ALL并不足以重置所有会话状态：

• 会话级只读状态未重置：如果某个连接曾被用于执行SET SESSION READ ONLY（比如Spring的只读事务可能触发这个设置，取决于Hibernate版本和配置），DISCARD ALL不会重置这个会话级属性，导致后续复用该连接的事务默认是只读。可以修改server_reset_query为：

  server_reset_query = SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE; DISCARD ALL;
  

  强制把会话的默认事务模式改回可写。
• 检查连接池中的事务残留：模拟场景：手动在一个连接上开启只读事务，不提交直接放回池，然后复用该连接执行写操作，看是否复现错误。同时查看pgbouncer日志，确认server_reset_query是否在连接归还时被执行。
• PostgreSQL端监控连接状态：开启PostgreSQL的log_statement=all和log_transaction_states日志，当异常发生时，回溯对应连接的历史操作，看是否存在未正确结束的只读事务，或者会话级的只读设置。

3. 排查线程上下文的事务状态污染 #

JMS容器使用线程池处理消息，如果线程池的线程没有正确清理ThreadLocal中的事务状态，会导致后续任务继承错误的事务属性：

• 检查线程池的事务清理逻辑：Spring的事务是绑定到ThreadLocal的，线程处理完一个消息后，需要确保TransactionSynchronizationManager的资源被彻底清理。可以通过自定义JMS容器的任务装饰器，在任务执行前后显式清理线程上下文。
• 隔离JMS任务的事务上下文：确保每个JMS消息处理的事务是独立的，不会复用之前线程的事务状态。比如配置JMS容器的事务管理器时，明确设置事务的传播行为为REQUIRES_NEW。

4. 排查Hibernate/JPA的隐式写操作 #

有时候Hibernate的自动行为会在只读事务中触发写操作：

• 检查实体的序列生成策略：如果实体主键用SEQUENCE生成，Hibernate是否会在某些意外场景（比如加载实体时误判为新实体）调用nextval()？可以查看异常栈中的persist()调用来源，确认是业务代码主动调用，还是Hibernate的内部触发。
• 排查Hibernate事件监听器/拦截器：如果自定义了Hibernate的监听器（比如PostLoadEventListener），是否在只读事务中触发了实体的修改或持久化操作？
• 二级缓存的更新操作：如果开启了二级缓存，某些缓存同步操作是否会意外触发写数据库的逻辑？

5. 验证连接池与Spring事务的配合 #

确保Spring的事务管理器和pgbouncer的连接池正确协同：

• 检查连接的获取与释放时机：Spring的事务管理器应该在事务开始时获取连接，事务结束后释放连接回池。如果存在连接提前释放的情况（比如错误的配置导致连接在事务未完成时归还），会导致后续操作复用处于异常状态的连接。
• 测试pgbouncer的session模式行为：session模式下，每个客户端会话绑定一个服务器连接直到客户端断开，确认Spring的连接池（比如HikariCP）与pgbouncer的配合是否正确，没有出现连接共享或提前释放的情况。

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