Cursors and Transactions

If there is a transaction active in a session, cursors operate in the context of that transaction. Reads performed while a transaction is active inherit the isolation level of the transaction, and updates performed within a transaction are made durable by calling WT_SESSION::commit_transaction, or discarded by calling WT_SESSION::rollback_transaction.

If no transaction is active, cursor reads are performed at the isolation level of the session, set with the isolation configuration key to WT_CONNECTION::open_session and successful updates are automatically committed before the update operation completes.

Any operation that consists of multiple related updates should be enclosed in an explicit transaction to ensure that the updates are applied atomically.

At read-committed (the default) or snapshot isolation levels, committed changes from concurrent transactions become visible when no cursor is positioned. In other words, at these isolation levels, all cursors in a session read from a stable snapshot while any cursor in the session remains positioned.

Cursor positions do not survive transaction boundaries. When a transaction is started with the WT_SESSION::begin_transaction or ended with either WT_SESSION::commit_transaction or WT_SESSION::rollback_transaction, all open cursors are reset, as if the WT_CURSOR::reset method was called. The cursor reset discards any cursor position as well as the key and value.

Applications that need to continue an operation across a transaction boundary must make a copy of the cursor's key, and re-position the cursor with WT_CURSOR::search to continue the operation, dealing with cases where the record may no longer be available due to a WT_CURSOR::remove or WT_SESSION::rollback_transaction.

See Transactions for more information.

Cursor types

The following are some of the common builtin cursor types:

URI	Type	Notes
`backup:`	hot backup cursor	See also: Hot backup
`colgroup:<tablename>.<columnset>`	column group cursor
`config:[<uri>]`	object configuration cursor	(key=config string, value=config value)
`file:<filename>`	file cursor (key=file key, value=file value)
`index:<tablename>.<indexname>`	index cursor (key=index key, value=table value)
`lsm:<name>`	LSM cursor (key=LSM key, value=LSM value)	See also: Log-Structured Merge Trees
`statistics:[file:<filename>]`	database or file statistics (key=(int), value=(string)description, (string)value, (uint64_t)value)
`table:<tablename>`	table cursor (key=table key, value=table value)

See Data Sources for the full list.

Projections

Cursors on tables, column groups and indices can return a subset of columns. This is done by listing the column names in parenthesis in the uri parameter to WT_SESSION::open_cursor. Only the fields from the listed columns are returned by WT_CURSOR::get_value.

This is particularly useful with index cursors, because if all columns in the projection are available in the index (including primary key columns, which are the values of the index), the data can be read from the index without accessing any column groups. See Indices for more details.

Raw mode

Cursors can be configured for raw mode by specifying the "raw" config keyword to WT_SESSION::open_cursor. In this mode, the methods WT_CURSOR::get_key, WT_CURSOR::get_value, WT_CURSOR::set_key and WT_CURSOR::set_value all take a single WT_ITEM in the variable-length argument list instead of a separate argument for each column.

For WT_CURSOR::get_key and WT_CURSOR::get_value in raw mode, the WT_ITEM can be split into columns by calling wiredtiger_struct_unpack with the cursor's key_format or value_format, respectively. For WT_CURSOR::set_key and WT_CURSOR::set_value in raw mode, the WT_ITEM should be equivalent to calling wiredtiger_struct_pack for the cursor's key_format or value_format, respectively.