Not yet supported in WiredTiger.
This page describes the expected behavior of the 2.X releases.
Transactions provide a powerful abstraction for multiple threads to operate on data concurrently because they have the following properties:
To configure for transactions, the database must be created with transaction support enabled. This is done by passing the configuration string "transactional"
to wiredtiger_open when creating the database.
In WiredTiger, the transactional context is managed by the WT_SESSION class. Applications call WT_SESSION::begin_transaction to start a new transaction, which is only permitted when no cursors are open. Operations performed with that WT_SESSION handle are then part of the transaction, and their effects can be committed by calling WT_SESSION::commit_transaction or WT_SESSION::rollback_transaction, both of which implicitly close any open cursors.
When transactions are used, operations may fail with additional errors such as WT_DEADLOCK.
WiredTiger uses an optimistic concurrency control algorithm. This avoids the bottleneck of a centralized lock manager and expensive graph searching to identify deadlock cycles.
The default isolation level is serializable
, which means that the concurrent execution of committed transactions is equivalent to executing the transactions in some serial order.
Weaker isolation levels are also provided, including repeatable read
, which permits phantoms, snapshot isolation
, which permits write skew, read committed
, which permits lost updates and always returns the most recently committed changes, and read uncommitted
, which always reads the most recent version of data, regardless of whether it is committed.
Recovery is run automatically during wiredtiger_open when required.
Recovery works by using a database log that contains a record of the actions of all transactions. Recovery first finds the last complete checkpoint, and then scans forward through the log from that point to determine which transactions committed after the checkpoint. All actions are rolled forward from the checkpoint so that the in-memory tree matches its state when the crash occurred. Then the "losing" transactions (those that did not commit) are rolled back to return the database to a consistent state.
This suggests the importance of regular checkpoints: they limit the amount of work required during recovery, which speeds up the wiredtiger_open call. See WT_SESSION::checkpoint for information about triggering checkpoints.
The code below is taken from the complete example program ex_transaction.c, available in the source tree as examples/c/\1
.
session->begin_transaction(session, NULL); /* ... */ session->commit_transaction(session, NULL);