spring-spanner write-sessions的keep-alive机制为何未触发预期abort？

先澄清几个容易混淆的认知偏差 #

你之前的理解有三个核心的认知错位，刚好对应了你观察到的矛盾点：

• 连接池里闲置的write-session，不会预先绑定正在运行的read-write事务。read-write事务只有当应用真正发起写操作、需要执行业务事务逻辑时，才会在从池里取出的session上临时开启，不会提前把事务挂在闲置session上占用资源。
• 你提到的「read-write事务最后一条SQL执行后10秒无操作就触发abort」规则，仅适用于已经激活、被应用持有、还没完成提交/回滚的活跃事务，和闲置在连接池里的空session没有关系。
• keep-alive执行的select 1探活查询，根本不是在某个预绑定的read-write事务内跑的。

机制实际运行的完整流程 #

为什么keep-alive按30分钟间隔执行探活，完全不会触发事务abort？可以顺着逻辑拆成三层：

1. 闲置session的状态本身就不受10秒事务超时规则约束
   没有绑定任何活跃事务的空write-session，本质是和Spanner服务端维持的长期gRPC连接。服务端对这类完全空闲的连接的回收阈值是30分钟左右，远高于活跃事务的10秒abort阈值。只要session上没有挂着未完成的用户事务，哪怕连续几十秒没有任何操作，也不会触发abort。
2. keep-alive的探活逻辑完全不触碰事务上下文
   定时触发的select 1，走的是单条自动提交的临时只读事务流程：查询执行完立刻销毁对应的事务上下文，不会在session上残留任何事务句柄。这个操作的唯一作用是给空连接打个流量标记，告诉服务端这条连接还在被客户端使用，不要因为长时间无流量就回收连接，全程根本不会和未激活的用户事务产生交集。
3. 会触发abort的场景和keep-alive的运行场景完全不重叠
   只有当session被从连接池取出、绑定了正式的用户read-write事务，之后连续10秒没有任何事务内的SQL执行、提交/回滚操作时，服务端才会abort这个事务。这种状态下的session已经被应用持有，根本不会留在连接池里参与定时keep-alive探活，自然不存在“探活完10秒就abort”的情况。

两层超时规则的适用边界完全独立：

• 10秒abort规则：针对「已激活、被应用持有的未提交read-write事务」
• 30分钟连接回收规则：针对「闲置在连接池、没有绑定任何活跃事务的空session」

keep-alive的作用就是定期给后者打流量，避免空连接被服务端回收，全程因为没有活跃事务存在，自然不会触发abort逻辑。

补充容易忽略的实现细节 #

Spring Spanner的连接池在把session放回池之前，会强制执行事务清理操作：如果session上还残留没提交/回滚的事务，会主动执行回滚把状态清空。正常运行状态下，池里的闲置session不会带着未完成的用户事务，也就不会出现探活查询误触发事务abort的异常情况。

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