diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/ch13s02.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/ch13s02.html')
| -rw-r--r-- | docs/programmer_reference/ch13s02.html | 62 |
1 files changed, 31 insertions, 31 deletions
diff --git a/docs/programmer_reference/ch13s02.html b/docs/programmer_reference/ch13s02.html index 65bfe350..d66215d9 100644 --- a/docs/programmer_reference/ch13s02.html +++ b/docs/programmer_reference/ch13s02.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="xa.html">Prev</a> </td> - <th width="60%" align="center">Chapter 13. - Distributed Transactions - </th> + <th width="60%" align="center">Chapter 13. Distributed Transactions </th> <td width="20%" align="right"> <a accesskey="n" href="xa_build.html">Next</a></td> </tr> </table> @@ -34,35 +32,39 @@ <div class="titlepage"> <div> <div> - <h2 class="title" style="clear: both"><a id="idp2523200"></a>Berkeley DB XA Implementation</h2> + <h2 class="title" style="clear: both"><a id="idp2294328"></a>Berkeley DB XA Implementation</h2> </div> </div> </div> <p> -Berkeley DB provides support for distributed transactions using the two-phase commit protocol - via its <a href="../api_reference/C/txnprepare.html" class="olink">DB_TXN->prepare()</a> interfaces. - The <a href="../api_reference/C/txnprepare.html" class="olink">DB_TXN->prepare()</a> 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 -<a href="../api_reference/C/txnrecover.html" class="olink">DB_ENV->txn_recover()</a> method when it is called during recovery. - </p> + Berkeley DB provides support for distributed transactions + using the two-phase commit protocol via its <a href="../api_reference/C/txnprepare.html" class="olink">DB_TXN->prepare()</a> interfaces. + The <a href="../api_reference/C/txnprepare.html" class="olink">DB_TXN->prepare()</a> 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 + <a href="../api_reference/C/txnrecover.html" class="olink">DB_ENV->txn_recover()</a> method when it is called during recovery. + </p> <p> -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. -</p> - <p>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.</p> + 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. + </p> + <p> + 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. + </p> </div> <div class="navfooter"> <hr /> @@ -75,9 +77,7 @@ will be consistent across the multiple environments.</p> <td width="40%" align="right"> <a accesskey="n" href="xa_build.html">Next</a></td> </tr> <tr> - <td width="40%" align="left" valign="top">Chapter 13. - Distributed Transactions - </td> + <td width="40%" align="left" valign="top">Chapter 13. Distributed Transactions </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> |