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

@@ -42,62 +40,105 @@

- Is it possible to mix XA and non-XA transactions? + Is it possible to mix XA and non-XA + transactions? -
Yes. It is also possible for XA and non-XA transactions to coexist in -the same Berkeley DB environment. To do this, specify the same environment -to the non-XA DB_ENV->open() calls as was specified in the Tuxedo -configuration file.
+
+ Yes. It is also possible for XA and non-XA + transactions to coexist in the same Berkeley DB + environment. To do this, specify the same environment + to the non-XA DB_ENV->open() calls as was specified in the + Tuxedo configuration file. +
- Does converting an application to run within XA change any of -the already existing C/C++ API calls it does? + Does converting an application to + run within XA change any of the already existing C/C++ + API calls it does? -
When converting an application to run under XA, the application's Berkeley DB calls are unchanged, with three exceptions:
+
+ When converting an application to run under XA, the + application's Berkeley DB calls are unchanged, with + three exceptions: +
1. The application must specify the DB_XA_CREATE flag to -the db_create() function.
2. Unless the application is performing an operation for a non-XA transaction, the application should never explicitly call DB_TXN->commit(), DB_TXN->abort(), and DB_ENV->txn_begin(), and those calls should be replaced by calls into the Tuxedo transaction manager.
3. Unless the application is performing an operation for a non-XA transaction, the application should specify a transaction argument of NULL to Berkeley DB methods taking transaction arguments (for example, DB->put() or DB->cursor()).
4. + The application must specify the + DB_XA_CREATE flag to the db_create() + function. +
5. + Unless the application is performing an + operation for a non-XA transaction, the + application should never explicitly call + DB_TXN->commit(), DB_TXN->abort(), and DB_ENV->txn_begin(), and those + calls should be replaced by calls into the Tuxedo + transaction manager. +
6. + Unless the application is performing an + operation for a non-XA transaction, the + application should specify a transaction argument + of NULL to Berkeley DB methods taking transaction + arguments (for example, DB->put() or + DB->cursor()). +
-
Otherwise, the application should be unchanged.
+
+ Otherwise, the application should be + unchanged. +
- How does Berkeley DB recovery interact with recovery by the Tuxedo -transaction manager? + How does Berkeley DB recovery + interact with recovery by the Tuxedo transaction + manager? -
Recovery is completed in two steps. First, each resource manager should -recover its environment(s). This can be done via a program that calls -DB_ENV->open() or by calling the db_recover utility. If using the db_recover utility, then the option -should be specified so that the regions that are recovered persist after -the utility exits. Any transactions that were prepared, but neither -completed nor aborted, are restored to their prepared state so that they -may be aborted or committed via the Tuxedo recovery mechanisms. After -each resource manager has recovered, then Tuxedo recovery may begin. -Tuxedo will interact with each resource manager via the __db_xa_recover -function which returns the list of prepared, but not yet completed -transactions. It should issue a commit or abort for each one, and only -after having completed each transaction will normal processing resume.
-
Finally, standard log file archival and catastrophic recovery procedures -should occur independently of XA operation.
+
+ Recovery is completed in two steps. First, each + resource manager should recover its environment(s). + This can be done via a program that calls DB_ENV->open() or + by calling the db_recover utility. If using the + db_recover utility, then the + teoption should be specified so that + the regions that are recovered persist after the + utility exits. Any transactions that were prepared, + but neither completed nor aborted, are restored to + their prepared state so that they may be aborted or + committed via the Tuxedo recovery mechanisms. After + each resource manager has recovered, then Tuxedo + recovery may begin. Tuxedo will interact with each + resource manager via the __db_xa_recover function + which returns the list of prepared, but not yet + completed transactions. It should issue a commit or + abort for each one, and only after having completed + each transaction will normal processing resume. +
+
+ Finally, standard log file archival and catastrophic + recovery procedures should occur independently of XA + operation. +
- Does Berkeley DB provide multi-threaded support for XA transactions? + Does Berkeley DB provide + multi-threaded support for XA transactions? -
-Yes. -For information on how to build multi-threaded servers for XA transactions, -see http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html. -All databases used by servers should be opened with handles created with the DB_XA_CREATE flag in the db_create() method and must be opened in the tpsvrinit routine. -Note that the environment parameter of the db_create() method must be assigned NULL. -For more information on the tpsvrinit routine, see http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html. - -
+
+ Yes. For information on how to build multi-threaded + servers for XA transactions, see http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html. + All databases used by servers should be opened + with handles created with the DB_XA_CREATE flag in + the db_create() method and must be opened in the + tpsvrinit routine. Note that the environment parameter + of the db_create() method must be assigned NULL. For + more information on the tpsvrinit routine, see http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html. +