Transactions provide a powerful abstraction for multiple threads to operate on data concurrently because they have the following properties:
WiredTiger supports transactions with the following caveats to the ACID properties:
In WiredTiger, transaction operations are methods off the Session class.
Applications call Session.begin_transaction to start a new transaction. Operations subsequently performed using that Session handle, including operations on any cursors open in that Session handle (whether opened before or after the Session.begin_transaction call), are part of the transaction and their effects committed by calling Session.commit_transaction, or discarded by calling Session.rollback_transaction.
If Session.commit_transaction returns an error for any reason, the transaction was rolled back, not committed.
When transactions are used, data operations can encounter a conflict and fail with the WT_ROLLBACK error. If this error occurs, transactions should be rolled back with Session.rollback_transaction and the operation retried.
The Session.rollback_transaction method implicitly resets all cursors in the session as if the Cursor.reset method was called, discarding any cursor position as well as any key and value.
If a cursor is used when no explicit transaction is active in a session, reads are performed at the isolation level of the session, set with the
isolation key to Connection.open_session, and successful updates are automatically committed before the update operation returns.
Any operation consisting of multiple related updates should be enclosed in an explicit transaction to ensure the updates are applied atomically.
If an implicit transaction successfully commits, the cursors in the Session remain positioned. If an implicit transaction fails, all cursors in the Session are reset, as if Cursor.reset were called, discarding any position or key/value information they may have.
See Cursors and Transactions for more information.
WiredTiger uses optimistic concurrency control algorithms. This avoids the bottleneck of a centralized lock manager and ensures transactional operations do not block: reads do not block writes, and vice versa.
Further, writes do not block writes, although concurrent transactions updating the same value will fail with WT_ROLLBACK. Some applications may benefit from application-level synchronization to avoid repeated attempts to rollback and update the same value.
Operations in transactions may also fail with the WT_ROLLBACK error if some resource cannot be allocated after repeated attempts. For example, if the cache is not large enough to hold the updates required to satisfy transactional readers, an operation may fail and return WT_ROLLBACK.
snapshot isolation levels; the default isolation level is
read-uncommitted: Transactions can see changes made by other transactions before those transactions are committed. Dirty reads, non-repeatable reads and phantoms are possible.
read-committed: Transactions cannot see changes made by other transactions before those transactions are committed. Dirty reads are not possible; non-repeatable reads and phantoms are possible. Committed changes from concurrent transactions become visible when no cursor is positioned in the read-committed transaction.
snapshot: Transactions read the versions of records committed before the transaction started. Dirty reads and non-repeatable reads are not possible; phantoms are possible.
The transaction isolation level can be configured on a per-transaction basis:
Additionally, the default transaction isolation can be configured and re-configured on a per-session basis:
Applications can create named snapshots by calling Session.snapshot with a configuration that includes
"name=foo". This configuration creates a new named snapshot, as if a snapshot isolation transaction were started at the time of the Session.snapshot call.
Subsequent transactions can be started "as of" that snapshot by calling Session.begin_transaction with a configuration that includes
snapshot=foo. That transaction will run at snapshot isolation as if the transaction started at the time of the Session.snapshot call that created the snapshot.
Named snapshots keep data pinned in cache as if a real transaction were running for the time that the named transaction is active. The resources associated with named snapshots should be released by calling Session.snapshot with a configuration that includes
"drop=". See Session.snapshot documentation for details of the semantics supported by the drop configuration.
Named snapshots are not durable: they do not survive Connection.close.