5.1. Transactions

To find out at runtime whether or not the driver associated with the current connection supports transactions, use the function dbi_conn_cap_get to query if the "transaction_support" capability is nonzero. Drivers should throw an error if transaction-related functions are called although the database engine does not support them. If a database engine supports both transaction-safe and non-transaction safe table types, the behaviour of the driver depends on its implementation.

Transactions are usually handled by a standard sequence of actions. First, the transaction is set up. Then one or more commands are executed. Based on the result of these commands, the transaction can either be aborted (rolled back) or be written to the database (committed). libdbi provides the following functions to handle these tasks:

Start a transaction

Some database engines start a transaction after a connection is established, and after each transaction is finished. These database engines do not strictly need a command to start a transaction. Others work in autocommit mode, i.e. each command is automatically committed. Some of the latter can be coerced to use transactions, while others simply do not provide explicit transaction management. As a database abstraction layer, libdbi has to cover all cases by providing an explicit command to start transactions, see dbi_conn_transaction_begin.

Commit a transaction

If no errors occurred during a transaction, the changes can actually be written to the database by calling dbi_conn_transaction_commit.

Rollback a transaction

If an error occurred during a transaction, the database can be reverted to the state when the transaction started by calling dbi_conn_transaction_rollback.