OperationAborted异常表明MongoDB服务端单方面中止事务，非客户端主动abort；常见原因包括网络断连、事务超时、线程异常退出或连接池复用stale连接。
OperationAborted 异常说明：事务被强制中止，不是你主动 abort() 的
OperationAborted 是 MongoDB 驱动抛出的明确信号：事务已由服务端单方面终止，客户端未收到显式错误就丢失了会话上下文。它常伴随 Session was closed 或 Session is no longer valid 日志，但根本原因往往不在你的 session.abortTransaction() 调用里——而在于会话生命周期被外部因素提前终结。
为什么 ClientSession 会被被动关闭？常见触发点
驱动层不会无故丢弃会话，所有被动关闭都源于底层连接或服务端策略干预：
- 网络抖动导致 TCP 连接断开，驱动检测到 socket 关闭后自动回收关联的
ClientSession - 服务端设置了
transactionLifetimeLimitSeconds（默认 60 秒），事务内操作耗时超限，mongod 主动 kill 会话并清理资源 - 客户端线程异常退出（如 JVM crash、线程池 reject、未 catch 的
RuntimeException），导致ClientSession对象被 GC，而驱动未收到 close 通知 - 使用了连接池中的 stale connection：该连接曾被其他请求占用过，且上次使用后未正确结束事务，服务端已将其标记为不可复用
如何定位 Session 关闭源头？关键检查项
别只盯着业务代码里的 commitTransaction()，先确认会话是否真的“活”到了那一步：
- 在事务块最外层加日志：
log.info("session id: {}", session.getSessionId())，对比异常发生前后的 session ID 是否一致 - 开启驱动调试日志：
logging.level.org.mongodb.driver=DEBUG，搜索closeSession、endSession、connection lost等关键词 - 检查 mongod 日志（需有
verbosity: 2）：查找包含aborting transaction for session或session expired的行，确认是超时还是服务端主动清理 - 验证连接字符串是否含
?maxIdleTimeMS=60000—— 若设得太小（如 10s），空闲会话可能在事务执行中途被连接池回收
修复建议：让 Session 活得久一点、稳一点
被动关闭本质是会话与连接的“弱绑定”被现实条件打破，修复重点在延长生命周期可控性：
- 显式控制事务超时：在
withTransaction()或手动事务块中传入TransactionOptions().timeout(30, TimeUnit.SECONDS)，值必须 transactionLifetimeLimitSeconds - 避免跨线程复用
ClientSession：它不是线程安全的，若用在异步流（如 CompletableFuture）、线程池任务中，务必确保整个事务逻辑在同一线程内完成 - 禁用连接池自动清理干扰：移除连接字符串里的
minPoolSize和maxPoolSize以外的闲置参数，或设maxIdleTimeMS=0（禁用空闲驱逐） - 事务前 ping 会话：
session.getServerDescription()可触发一次轻量握手，提前暴露连接失效问题，比等到 commit 时才发现更可控
真正棘手的是那些不报错但静默失效的情况——比如会话对象还存在，session.hasActiveTransaction() 却返回 false。这种时候，不要假设驱动“应该”帮你续命，得靠日志和 timeout 主动兜底。
