Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual

Drivers API

On this page

  • Callback API vs Core API
  • Callback API
  • Core API
  • Driver Versions
  • Transaction Error Handling
  • Additional Information

The Callback API:

The Core API:

The callback API incorporates logic:

Starting in MongoDB 6.2, the server does not retry the transaction if it receives a TransactionTooLargeForCache error.


Use the Select your language drop-down menu in the upper-right to set the language of the examples on this page.


The core transaction API does not incorporate retry logic for errors labeled:


Use the Select your language drop-down menu in the upper-right to set the language of the examples on this page.


The following example incorporates logic to retry the transaction for transient errors and retry the commit for unknown commit error:

For transactions on MongoDB 4.2 deployments (replica sets and sharded clusters), clients must use MongoDB drivers updated for MongoDB 4.2:

Regardless of the database system, whether MongoDB or relational databases, applications should take measures to handle errors during transaction commits and incorporate retry logic for transactions.

The individual write operations inside the transaction are not retryable, regardless of the value of retryWrites. If an operation encounters an error associated with the label "TransientTransactionError", such as when the primary steps down, the transaction as a whole can be retried.

  • The callback API incorporates retry logic for "TransientTransactionError".

  • The core transaction API does not incorporate retry logic for "TransientTransactionError". To handle "TransientTransactionError", applications should explicitly incorporate retry logic for the error. To view an example that incorporates retry logic for transient errors, see Core API Example.

Commit operations are retryable write operations. If the commit operation encounters an error, MongoDB drivers retry the commit regardless of the value of retryWrites.

If the commit operation encounters an error labeled "UnknownTransactionCommitResult", the commit can be retried.

  • The callback API incorporates retry logic for "UnknownTransactionCommitResult".

  • The core transaction API does not incorporate retry logic for "UnknownTransactionCommitResult". To handle "UnknownTransactionCommitResult", applications should explicitly incorporate retry logic for the error. To view an example that incorporates retry logic for unknown commit errors, see Core API Example.

New in version 6.2.

Starting in MongoDB 6.2, the server does not retry the transaction if it receives a TransactionTooLargeForCache error. This error means the cache is too small and a retry is likely to fail.

The default value for the transactionTooLargeForCacheThreshold threshold is 0.75. The server returns TransactionTooLargeForCache instead of retrying the transaction when the transaction uses more than 75% of the cache.

In earlier versions of MongoDB, the server returns TemporarilyUnavailable or WriteConflict instead of TransactionTooLargeForCache.

Use the setParameter command to modify the error threshold.

On sharded clusters with multiple mongos instances, performing transactions with drivers updated for MongoDB 4.0 (instead of MongoDB 4.2) will fail and can result in errors, including:

Note

Your driver may return a different error. Refer to your driver's documentation for details.

Error Code
Error Message
251
cannot continue txnId -1 for session ... with txnId 1
50940
cannot commit with no participants

For transactions on MongoDB 4.2 deployments (replica sets and sharded clusters), use the MongoDB drivers updated for MongoDB 4.2

The following mongosh methods are available for transactions:

Note

The mongosh example omits retry logic and robust error handling for simplicity's sake. For a more practical example of incorporating transactions in applications, see Transaction Error Handling instead.

// Create collections:
db.getSiblingDB("mydb1").foo.insertOne(
{abc: 0},
{ writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
{xyz: 0},
{ writeConcern: { w: "majority", wtimeout: 2000 } }
)
// Start a session.
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// Start a transaction
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// Operations inside the transaction
try {
coll1.insertOne( { abc: 1 } );
coll2.insertOne( { xyz: 999 } );
} catch (error) {
// Abort transaction on error
session.abortTransaction();
throw error;
}
// Commit the transaction using write concern set at transaction start
session.commitTransaction();
session.endSession();
←  TransactionsProduction Considerations →