Production Limits: Runtime, Locking, Sharded Costs, DDL Restrictions, and Abort Scenarios

Learning objectives

1. Transactions are bounded coordination, not an unlimited batch primitive

MongoDB's default transactionLifetimeLimitSeconds is 60 seconds. A periodic cleanup process aborts expired transactions. By default, a transaction waits up to maxTransactionLockRequestTimeoutMillis=5 milliseconds for required locks before it aborts. Those are defaults, not universal tuning targets; production changes require workload evidence and, in Atlas, server-parameter changes may require service-specific controls/support.

Large transactions also retain more WiredTiger history/cache state. Since MongoDB writes separate oplog entries as needed, there is no old 16 MiB total transaction oplog-entry limit, but each individual oplog entry remains subject to the 16 MiB BSON document limit.

2. Observe actual limits and create one hot document

const c=db.locks_ch13_l4;c.drop();c.insertOne({_id:"hot-doc",tenantId:"tenant-a",counter:0});printjson(db.getSiblingDB("admin").runCommand({  getParameter:1,  transactionLifetimeLimitSeconds:1,  maxTransactionLockRequestTimeoutMillis:1}));

3. Controlled lock/write-conflict experiment

Session 1 updates the document and remains open. Session 2 then tries to update the same document. Depending on the exact conflict path, the second operation should fail/abort rather than silently interleave both transaction writes. The first session commits, and the final counter should reflect only its increment.

const s1=db.getMongo().startSession();const s2=db.getMongo().startSession();const c1=s1.getDatabase("atlasmart").locks_ch13_l4;const c2=s2.getDatabase("atlasmart").locks_ch13_l4;s1.startTransaction({readConcern:{level:"snapshot"},writeConcern:{w:"majority"}});c1.updateOne({_id:"hot-doc"},{$inc:{counter:1}});printjson(db.getSiblingDB("admin").aggregate([  {$currentOp:{allUsers:true,idleSessions:true}},  {$match:{transaction:{$exists:true}}},  {$project:{_id:0,type:1,lsid:1,transaction:1}}]).toArray());s2.startTransaction({readConcern:{level:"snapshot"},writeConcern:{w:"majority"}});try {  c2.updateOne({_id:"hot-doc"},{$inc:{counter:100}});  s2.commitTransaction();  print("unexpected: second transaction committed");} catch (e) {  print("second transaction failed while first held the conflicting write:",e.code,e.message);  try { s2.abortTransaction(); } catch (_) {}}s1.commitTransaction();printjson(db.locks_ch13_l4.findOne({_id:"hot-doc"}));s1.endSession(); s2.endSession();

4. Operation restrictions and DDL nuance

Transactions allow many CRUD operations across documents, collections, databases, and shards, but not every operation is legal. Aggregation stages such as $out, $merge, $currentOp, $planCacheStats, and several session-listing stages are prohibited inside transactions. Parallel operations in one transaction are unsupported.

DDL rules are nuanced rather than “DDL is always forbidden.” Current MongoDB supports creating collections and indexes in transactions in supported cases; explicit creation requires transaction read concern local. A cross-shard write transaction cannot create a new collection on another shard. Metadata operations can also wait behind transactions and create lock contention.

const s=db.getMongo().startSession();const sdb=s.getDatabase("atlasmart");s.startTransaction({readConcern:{level:"snapshot"},writeConcern:{w:"majority"}});try {  sdb.locks_ch13_l4.aggregate([{$set:{copy:1}},{$out:"should_not_exist_ch13_l4"}]).toArray();  print("unexpected: $out succeeded inside transaction");} catch (e) {  print("expected transaction restriction:",e.code,e.message);  try { s.abortTransaction(); } catch (_) {}}print("target exists:",db.getCollectionNames().includes("should_not_exist_ch13_l4"));s.endSession();

5. Why sharded transactions cost more coordination

A replica-set transaction coordinates one replica-set participant. A transaction whose writes span shards has multiple participants and a transaction coordinator that drives a distributed commit decision. That introduces network hops, participant availability dependencies, coordinator state/recovery, and chunk-migration interactions. The following code is a conceptual state-path model only; it does not claim to execute MongoDB’s internal protocol.

function coordination(participants) {  if (participants <= 1) {    return {participants,conceptualPath:["execute writes","commit replica-set transaction"]};  }  return {    participants,    conceptualPath:["execute writes on participant shards","prepare/coordinate decision","persist commit decision","notify participants","return according to commit semantics"],    extraFailureSurface:["participant availability","coordinator recovery","chunk migration interaction","cross-shard latency"]  };}printjson(coordination(1));printjson(coordination(3));

On real sharded clusters, $currentOp.twoPhaseCommitCoordinator can expose participant counts, coordinator state, and decision progress. Chunk migration can block or abort transactions depending on interleaving. Outside reads with snapshot/linearizable or causal afterClusterTime behavior wait appropriately during commit; weaker outside reads may continue seeing before-transaction versions.

Production judgment. Keep transactions short and narrow. Alert on rising abort/retry rates, long timeOpenMicros, transaction cache pressure, lock waits, and coordinator latency. Avoid changing global timeout parameters just to mask a modeling or contention problem. Test DDL deployment windows separately from transactional traffic. On shards, measure transaction participant count and routing; a transaction that unexpectedly fans out can turn an ordinary write path into a distributed coordination hotspot.

Bridge. Lesson 5 takes a transaction-heavy order model and reduces the number of independent documents that need one commit.

docker rm -f atlasmart-mongo-ch13-l4docker volume rm atlasmart-mongo-ch13-l4-data

Authoritative references

• MongoDB 8.3 release notes — Current 8.3 release line and patch-sensitive server behavior.
• Atomicity and transactions — Single-document atomicity and guidance to minimize unnecessary distributed transactions.
• Transactions — Sessions, transaction read/write concern, read preference, and transaction semantics.
• Drivers API for transactions — Callback versus core APIs and retry labels for transient transactions and ambiguous commits.
• Transaction production considerations — Runtime, locking, cache, DDL, conflicts, and operational constraints.
• Sharded transaction considerations — Cross-shard snapshot semantics, commit coordination, migrations, and outside reads.
• Transactions and operations — Operations permitted and prohibited inside transactions.
• $currentOp — Session/transaction observability including lsid, txnNumber, timing, and sharded coordinators.
• PyMongo transactions — PyMongo session, with_transaction, retry, and callback behavior.
• PyMongo release notes — Current PyMongo 4.17 behavior and session APIs.
• mongosh release notes — Current mongosh 2.10.0 release baseline.
• Server parameters — Current default lock-request timeout and transaction parameters.