Production Considerations

Feature Compatibility

The featureCompatibilityVersion of all members of the replica set must be 4.0 or greater.

Runtime Limit

By default, a transaction must have a runtime of less than one minute. You can modify this limit using transactionLifetimeLimitSeconds. Transactions that exceeds this limit are considered expired and will be aborted by a periodic cleanup process.

Oplog Size Limit

When the transaction commits, a single oplog (operations log) entry is created if the transaction contains any write operations. That is, the individual operations in the transactions do not have a corresponding oplog entry. Instead, a single oplog entry contains all of the write operations within a transaction. The oplog entry for the transaction must be within the BSON document size limit of 16MB.

WiredTiger Cache

To prevent storage cache pressure from immobilizing the system:

  • When you abandon a transaction, abort the transaction.
  • When you encounter an error during individual operation in the transaction, abort the transaction and retry the transaction.

The transactionLifetimeLimitSeconds also ensures that expired transactions are aborted periodically to relieve storage cache pressure.

Lock Request Timeout

By default, transactions waits up to 5 milliseconds to acquire locks required by the operations in the transaction. If the transaction cannot acquire its required locks within the 5 milliseconds, the transaction aborts.

Increasing maxTransactionLockRequestTimeoutMillis allows operations in the transactions to wait the specified time to acquire the required locks. This can help obviate transaction aborts on momentary concurrent lock acquisitions, like fast-running metadata operations. However, this could possibly delay the abort of deadlocked transaction operations.


When creating or dropping a collection immediately before starting a transaction, if the collection is accessed within the transaction, issue the create or drop operation with write concern "majority" to ensure that the transaction can acquire the required locks.

Pending DDL Operations and Transactions

If a multi-document transaction is in progress, new DDL operations that affect the same database(s) wait behind the transaction. While these pending DDL operations exist, new transactions that access the same database as the pending DDL operations cannot obtain the required locks and will abort after waiting maxTransactionLockRequestTimeoutMillis. In addition, new non-transaction operations that access the same database will block until they reach their maxTimeMS limit.

To illustrate, compare the following two situations:

Consider a situation where an in-progress transaction performs various CRUD operations on the employees collection in the hr database. While that transaction is in progress, a separate transaction that accesses the foobar collection in the hr database can start and complete.

However, consider a situation where an in-progress transaction performs various CRUD operations on the employees collection in the hr database and a separate DDL operation is issued to create an index on the fluffy collection in the hr database. The DDL operation waits for the transaction to finish.

While the DDL operation is pending, a new transaction attempts to access the foobar collection in the hr database. If the DDL operation remains pending for maxTransactionLockRequestTimeoutMillis, the new transaction aborts.

←   Transactions Indexes  →