- Berkeley DB Reference Guide:
- Distributed Transactions
|
|
Berkeley DB provides support for distributed transactions using a two-phase commit protocol via its DB_TXN->prepare and DB_ENV->txn_recover interfaces. The DB_TXN->prepare method performs the first phase of a two-phase commit, flushing the log to disk, and associating a global transaction ID with the underlying Berkeley DB transaction. This global transaction ID should be used by the global transaction manager to identify the Berkeley DB transaction, and will be returned by the DB_ENV->txn_recover method when it is called during recovery.
Distributed transactions are necessary whenever an application wants to transaction-protect data in multiple Berkeley DB environments, even if those environments are on the same machine. However, Berkeley DB does not perform distributed deadlock detection, therefore it is the responsibility of the application to ensure that accesses in different environments cannot deadlock (this can be accomplished through careful ordering of operations to the multiple environments), or by using the DB_LOCK_NOWAIT option and eventually abort transactions that have been waiting "too long" (where "too long" is determined by an application-specific timeout).
In order to use the two-phase commit feature of Berkeley DB, an application must either implement its own global transaction manager or use an XA-compliant transaction manager (as Berkeley DB can act as an XA-compliant resource manager).
When using distributed transactions, there is no way to perform hot backups of multiple environments and guarantee that the backups are global-transaction-consistent across these multiple environments. If backups are desired, then all write transactions should be suspended; that is, active write transactions must be allowed to complete and no new write transactions should be begun. Once there are no active write transactions, the logs may be copied for backup purposes and the backup will be consistent across the multiple environments.
|
|