mongodb事务提交失败主因是服务端60秒空闲超时自动清理事务，非网络问题；需避免事务内混入http调用等阻塞操作，并正确设置max_commit_time_ms（仅commit阶段生效）及transactionoptions.maxtimems（事务总耗时上限）。
Spring Boot 中 MongoDB 事务提交失败报 ConnectionFailure 或 InvalidOperation，大概率不是网络问题，而是服务端已提前终止事务——你调 commit_transaction() 时，事务 ID 已失效。
为什么 commit 会“找不到事务”
根本原因不是客户端卡住，而是 MongoDB 服务端默认用 transactionLifetimeLimitSeconds（60 秒）限制事务空闲时间。一旦事务开启后没操作、或操作间隙太久，服务端直接清理上下文。此时再发 commit_transaction()，服务端无对应事务记录，就断连并抛 ConnectionFailure。
常见诱因包括：
- 事务内混入了非数据库操作，比如 HTTP 调用、文件读写、sleep(1000)，导致空闲时间超标
- 多个写操作之间有复杂业务逻辑计算，没做异步剥离
- 使用了
max_commit_time_ms却误以为它能延长整个事务生命周期（它只管 commit 阶段，不管事务开了多久）
PyMongo 驱动里怎么设 max_commit_time_ms
这个参数只在 commit_transaction() 调用时生效，必须作为关键字参数传入，不能写在 session 初始化或 URI 里。
正确写法：
with client.start_session() as session:
with session.start_transaction():
collection.update_one({"_id": 1}, {"$inc": {"count": 1}}, session=session)
# 其他操作...
session.commit_transaction(max_commit_time_ms=5000) # ✅ 仅此处有效
注意：
- 单位是毫秒，最小值为 1；设太大（如 30000）没意义，因为事务早被服务端 kill 了
- 它不解决“事务超时被删”的问题，只防止 commit 过程本身卡死（比如锁竞争、WiredTiger 写放大）
- 若 commit 阶段真超时，服务端返回
MaxTimeMSExpired，PyMongo 抛ExecutionTimeout，和ConnectionFailure是两类错误
Spring Boot + MongoTemplate 怎么控制事务时长
Spring Data MongoDB 的 MongoTemplate 不暴露 max_commit_time_ms，但你可以绕过封装，拿到底层 ClientSession 手动控制：
关键点：
- 用
MongoTemplate.executeInSession()获取原始 session - 调
session.startTransaction()时传TransactionOptions设置maxTimeMS（注意：这是事务总耗时上限，不是 commit 专用） - commit 仍走
session.commitTransaction()，但 Spring 不帮你传max_commit_time_ms，得反射或换原生驱动
示例（Java）：
MongoTemplate.executeInSession(session -> {
TransactionOptions opts = TransactionOptions.builder()
.maxTimeMS(12000) // ⚠️ 实测最大耗时 × 1.5，单位毫秒
.build();
session.startTransaction(opts);
try {
template.updateFirst(query, update, "col", session);
session.commitTransaction(); // Spring 不支持传 max_commit_time_ms
} catch (Exception e) {
session.abortTransaction();
throw e;
}
});
最容易被忽略的三个硬限制
很多超时问题改了参数也没用，是因为撞上了 MongoDB 底层硬约束：
-
maxTransactionLockRequestTimeoutMillis默认仅 5 毫秒：两个事务互相等锁超时就报WriteConflict，需用db.adminCommand({ setParameter: 1, maxTransactionLockRequestTimeoutMillis: 3000 })调高 - 事务总数据量不能超 16MB：批量写入前先
collection.estimatedDocumentCount()算体积，超了就拆批 - 跨分片事务中，任一分片响应慢，整个事务卡住——
db.currentOp({ "secs_running": { "$gt": 5 } })要重点看secs_running和host字段，定位慢分片
事务超时从来不是单点问题。它把索引缺失、锁等待、分片延迟、外部依赖全串在一起，查的时候别只盯着 commit 报错，先用 db.currentOp() 把活着的长事务揪出来。
