MongoDB 5.0参数maxTransactionLockRequestTimeoutMillis不生效问题咨询

这既不是操作错误，也不是MongoDB的bug，属于参数适用场景和实际冲突类型不匹配的正常行为。

核心逻辑说明 #

你配置的maxTransactionLockRequestTimeoutMillis参数，仅适用于事务等待行锁的悲观排队场景，而你遇到的WriteConflict(错误码112)是WiredTiger存储引擎乐观并发控制（OCC）的校验报错，二者触发逻辑完全独立：

• 当两个操作同时申请同一文档的写锁时，后提交的请求会进入锁等待队列，此时才会触发你配置的3秒超时逻辑，超时后才会返回错误。
• 你当前的测试场景中，两个事务同时修改同一文档，第一个事务的修改已经生成了未提交的新版本，第二个事务执行修改操作时，WiredTiger会立即校验到文档版本冲突，直接抛出WriteConflict错误，这个流程不进入锁等待队列，所以不会等待你配置的3秒超时。

参数生效验证方法 #

如果需要验证maxTransactionLockRequestTimeoutMillis的实际效果，可以调整测试流程：

1. 窗口1不开启事务，执行命令对目标文档加独占写锁：

db.test.find({_id: objId}).lock("write")

2. 窗口2开启事务执行update操作，此时事务会进入行锁等待队列，3秒后才会返回超时错误。

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