Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 13. - Distributed Transactions -	Chapter 13. Distributed Transactions	Next

@@ -34,35 +32,39 @@

Berkeley DB XA Implementation

-Berkeley DB provides support for distributed transactions using the two-phase commit protocol - via its DB_TXN->prepare() 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 is 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. -

+ Berkeley DB provides support for distributed transactions + using the two-phase commit protocol via its DB_TXN->prepare() 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 is 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. +

-However, Berkeley DB does not perform distributed deadlock detection. -Instead, when being used as an XA resource manager, Berkeley DB acquires all locks -in a non-blocking mode. This results in pre-emptive abort of transactions that have the potential to deadlock. -While this can lead to more transactions being aborted than is strictly necessary, -it avoids system-wide hanging due to distributed deadlocks. -

When using distributed transactions, there is no way to perform -hot backups of multiple environments and guarantee that the backups -are globally 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.

+ However, Berkeley DB does not perform distributed deadlock + detection. Instead, when being used as an XA resource manager, + Berkeley DB acquires all locks in a non-blocking mode. This + results in pre-emptive abort of transactions that have the + potential to deadlock. While this can lead to more transactions + being aborted than is strictly necessary, + it avoids system-wide hanging due to distributed deadlocks. +

+ When using distributed transactions, there is no way to perform + hot backups of multiple environments and guarantee that the backups + are globally 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. +