1<!--$Id: intro.so,v 10.7 2006/11/13 18:05:06 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Introduction to distributed transactions</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a><a name="3"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Distributed Transactions</dl></b></td> 14<td align=right><a href="/rep/ex_rq.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/xa/build.html"><img src="/images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Introduction to distributed transactions</b></p> 17<p>Berkeley DB provides support for distributed transactions using a two-phase 18commit protocol via its <a href="/api_c/txn_prepare.html">DB_TXN->prepare</a> and <a href="/api_c/txn_recover.html">DB_ENV->txn_recover</a> 19interfaces. The <a href="/api_c/txn_prepare.html">DB_TXN->prepare</a> method performs the first phase of a 20two-phase commit, flushing the log to disk, and associating a global 21transaction ID with the underlying Berkeley DB transaction. This global 22transaction ID should be used by the global transaction manager to 23identify the Berkeley DB transaction, and will be returned by the 24<a href="/api_c/txn_recover.html">DB_ENV->txn_recover</a> method when it is called during recovery.</p> 25<p>Distributed transactions are necessary whenever an application wants to 26transaction-protect data in multiple Berkeley DB environments, even if those 27environments are on the same machine. However, Berkeley DB does not perform 28distributed deadlock detection, therefore it is the responsibility of 29the application to ensure that accesses in different environments cannot 30deadlock (this can be accomplished through careful ordering of 31operations to the multiple environments), or by using the 32<a href="/api_c/lock_vec.html#DB_LOCK_NOWAIT">DB_LOCK_NOWAIT</a> option and eventually abort transactions that 33have been waiting "too long" (where "too long" is determined by an 34application-specific timeout).</p> 35<p>In order to use the two-phase commit feature of Berkeley DB, an application 36must either implement its own global transaction manager or use an 37XA-compliant transaction manager (as Berkeley DB can act as an XA-compliant 38resource manager).</p> 39<p>When using distributed transactions, there is no way to perform 40hot backups of multiple environments and guarantee that the backups 41are global-transaction-consistent across these multiple environments. 42If backups are desired, then all write transactions should be suspended; 43that is, active write transactions must be allowed to complete and no 44new write transactions should be begun. Once there are no active write 45transactions, the logs may be copied for backup purposes and the backup 46will be consistent across the multiple environments.</p> 47<table width="100%"><tr><td><br></td><td align=right><a href="/rep/ex_rq.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/xa/build.html"><img src="/images/next.gif" alt="Next"></a> 48</td></tr></table> 49<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 50</body> 51</html> 52