diff options
Diffstat (limited to 'docs/programmer_reference/xa_faq.html')
| -rw-r--r-- | docs/programmer_reference/xa_faq.html | 132 |
1 files changed, 86 insertions, 46 deletions
diff --git a/docs/programmer_reference/xa_faq.html b/docs/programmer_reference/xa_faq.html index cbc84922..29026a0a 100644 --- a/docs/programmer_reference/xa_faq.html +++ b/docs/programmer_reference/xa_faq.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_xa_restrict.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="apprec.html">Next</a></td> </tr> </table> @@ -42,62 +40,105 @@ <ol type="1"> <li> <span class="bold"> - <strong>Is it possible to mix XA and non-XA transactions?</strong> + <strong>Is it possible to mix XA and non-XA + transactions?</strong> </span> - <p>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 <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> calls as was specified in the Tuxedo -configuration file.</p> + <p> + 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 <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> calls as was specified in the + Tuxedo configuration file. + </p> </li> <li> <span class="bold"> - <strong>Does converting an application to run within XA change any of -the already existing C/C++ API calls it does?</strong> + <strong>Does converting an application to + run within XA change any of the already existing C/C++ + API calls it does?</strong> </span> - <p>When converting an application to run under XA, the application's Berkeley DB calls are unchanged, with three exceptions:</p> + <p> + When converting an application to run under XA, the + application's Berkeley DB calls are unchanged, with + three exceptions: + </p> <div class="orderedlist"> <ol type="a"> - <li>The application must specify the <a href="../api_reference/C/dbcreate.html#dbcreate_DB_XA_CREATE" class="olink">DB_XA_CREATE</a> flag to -the <a href="../api_reference/C/dbcreate.html" class="olink">db_create()</a> function.</li> - <li>Unless the application is performing an operation for a non-XA transaction, the application should never explicitly call <a href="../api_reference/C/txncommit.html" class="olink">DB_TXN->commit()</a>, <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a>, and <a href="../api_reference/C/txnbegin.html" class="olink">DB_ENV->txn_begin()</a>, and those calls should be replaced by calls into the Tuxedo transaction manager.</li> - <li>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, <a href="../api_reference/C/dbput.html" class="olink">DB->put()</a> or <a href="../api_reference/C/dbcursor.html" class="olink">DB->cursor()</a>).</li> + <li> + The application must specify the + <a href="../api_reference/C/dbcreate.html#dbcreate_DB_XA_CREATE" class="olink">DB_XA_CREATE</a> flag to the <a href="../api_reference/C/dbcreate.html" class="olink">db_create()</a> + function. + </li> + <li> + Unless the application is performing an + operation for a non-XA transaction, the + application should never explicitly call + <a href="../api_reference/C/txncommit.html" class="olink">DB_TXN->commit()</a>, <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a>, and <a href="../api_reference/C/txnbegin.html" class="olink">DB_ENV->txn_begin()</a>, and those + calls should be replaced by calls into the Tuxedo + transaction manager. + </li> + <li> + 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, <a href="../api_reference/C/dbput.html" class="olink">DB->put()</a> or + <a href="../api_reference/C/dbcursor.html" class="olink">DB->cursor()</a>). + </li> </ol> </div> - <p>Otherwise, the application should be unchanged.</p> + <p> + Otherwise, the application should be + unchanged. + </p> </li> <li> <span class="bold"> - <strong>How does Berkeley DB recovery interact with recovery by the Tuxedo -transaction manager?</strong> + <strong>How does Berkeley DB recovery + interact with recovery by the Tuxedo transaction + manager?</strong> </span> - <p>Recovery is completed in two steps. First, each resource manager should -recover its environment(s). This can be done via a program that calls -<a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> or by calling the <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> utility. If using the <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> 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.</p> - <p>Finally, standard log file archival and catastrophic recovery procedures -should occur independently of XA operation.</p> + <p> + Recovery is completed in two steps. First, each + resource manager should recover its environment(s). + This can be done via a program that calls <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> or + by calling the <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> utility. If using the + <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> 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. + </p> + <p> + Finally, standard log file archival and catastrophic + recovery procedures should occur independently of XA + operation. + </p> </li> <li> <span class="bold"> - <strong>Does Berkeley DB provide multi-threaded support for XA transactions?</strong> + <strong>Does Berkeley DB provide + multi-threaded support for XA transactions?</strong> </span> - <p> -Yes. -For information on how to build multi-threaded servers for XA transactions, -see <a class="ulink" href="http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html" target="_top">http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html</a>. -All databases used by servers should be opened with handles created with the <a href="../api_reference/C/dbcreate.html#dbcreate_DB_XA_CREATE" class="olink">DB_XA_CREATE</a> flag in the <a href="../api_reference/C/dbcreate.html" class="olink">db_create()</a> method and must be opened in the tpsvrinit routine. -Note that the environment parameter of the <a href="../api_reference/C/dbcreate.html" class="olink">db_create()</a> method must be assigned NULL. -For more information on the tpsvrinit routine, see <a class="ulink" href="http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html" target="_top">http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html</a>. - -</p> + <p> + Yes. For information on how to build multi-threaded + servers for XA transactions, see <a class="ulink" href="http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html" target="_top">http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html</a>. + All databases used by servers should be opened + with handles created with the <a href="../api_reference/C/dbcreate.html#dbcreate_DB_XA_CREATE" class="olink">DB_XA_CREATE</a> flag in + the <a href="../api_reference/C/dbcreate.html" class="olink">db_create()</a> method and must be opened in the + tpsvrinit routine. Note that the environment parameter + of the <a href="../api_reference/C/dbcreate.html" class="olink">db_create()</a> method must be assigned NULL. For + more information on the tpsvrinit routine, see <a class="ulink" href="http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html" target="_top">http://download.oracle.com/docs/cd/E13161_01/tuxedo/docs10gr3/pgc/pgthr.html</a>. + </p> </li> </ol> </div> @@ -117,9 +158,8 @@ For more information on the tpsvrinit routine, see <a class="ulink" href="http:/ <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Chapter 14. - Application Specific Logging and Recovery - </td> + <td width="40%" align="right" valign="top"> Chapter 14. Application Specific Logging and + Recovery </td> </tr> </table> </div> |