svn commit - mysqldoc@docsrva: r1373 - in trunk: . refman-5.0 refman-5.1

[paul]

Author: paul
Date: 2006-02-17 22:53:56 +0100 (Fri, 17 Feb 2006)
New Revision: 1373

Log:
 r7737@frost:  paul | 2006-02-17 15:45:50 -0600
 Update XA restrictions with info from Guilhem.


Modified:
   trunk/
   trunk/refman-5.0/restrictions.xml
   trunk/refman-5.1/restrictions.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7719
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7737
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223

Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml	2006-02-17 18:24:19 UTC (rev 1372)
+++ trunk/refman-5.0/restrictions.xml	2006-02-17 21:53:56 UTC (rev 1373)
@@ -958,16 +958,30 @@
 
     <para>
       If an XA transaction has reached the <literal>PREPARED</literal>
-      state and the MySQL server dies, the transaction can be continued
-      after the server restarts. That is as it should be. However, if
-      the client connection terminates and the server continues to run,
-      the server rolls back any pending XA transaction, even one that
-      has reached the <literal>PREPARED</literal> state. It should be
-      possible to commit or roll back a <literal>PREPARED</literal> XA
-      transaction, but this cannot be done without changes to the binary
-      logging mechanism.
+      state and the MySQL server is killed (for example, with
+      <command>kill -9</command> on Unix) or shuts down abnormally, the
+      transaction can be continued after the server restarts. However,
+      if the client reconnects and commits the transaction, the
+      transaction will be absent from the binary log even though it has
+      been committed. This means the data and the binary log have gone
+      out of synchrony. An implication is that XA cannot be used safely
+      together with replication.
     </para>
 
+    <para>
+      It is possible that the server will roll back a pending XA
+      transaction, even one that has reached the
+      <literal>PREPARED</literal> state. This happens if a client
+      connection terminates and the server continues to run, or if
+      clients are connected and the server shuts down gracefully. (In
+      the latter case, the server marks each connection to be
+      terminated, and then rolls back the <literal>PREPARED</literal> XA
+      transaction associated with it.) It should be possible to commit
+      or roll back a <literal>PREPARED</literal> XA transaction, but
+      this cannot be done without changes to the binary logging
+      mechanism.
+    </para>
+
   </section>
 
 </appendix>

Modified: trunk/refman-5.1/restrictions.xml
===================================================================
--- trunk/refman-5.1/restrictions.xml	2006-02-17 18:24:19 UTC (rev 1372)
+++ trunk/refman-5.1/restrictions.xml	2006-02-17 21:53:56 UTC (rev 1373)
@@ -934,16 +934,30 @@
 
     <para>
       If an XA transaction has reached the <literal>PREPARED</literal>
-      state and the MySQL server dies, the transaction can be continued
-      after the server restarts. That is as it should be. However, if
-      the client connection terminates and the server continues to run,
-      the server rolls back any pending XA transaction, even one that
-      has reached the <literal>PREPARED</literal> state. It should be
-      possible to commit or roll back a <literal>PREPARED</literal> XA
-      transaction, but this cannot be done without changes to the binary
-      logging mechanism.
+      state and the MySQL server is killed (for example, with
+      <command>kill -9</command> on Unix) or shuts down abnormally, the
+      transaction can be continued after the server restarts. However,
+      if the client reconnects and commits the transaction, the
+      transaction will be absent from the binary log even though it has
+      been committed. This means the data and the binary log have gone
+      out of synchrony. An implication is that XA cannot be used safely
+      together with replication.
     </para>
 
+    <para>
+      It is possible that the server will roll back a pending XA
+      transaction, even one that has reached the
+      <literal>PREPARED</literal> state. This happens if a client
+      connection terminates and the server continues to run, or if
+      clients are connected and the server shuts down gracefully. (In
+      the latter case, the server marks each connection to be
+      terminated, and then rolls back the <literal>PREPARED</literal> XA
+      transaction associated with it.) It should be possible to commit
+      or roll back a <literal>PREPARED</literal> XA transaction, but
+      this cannot be done without changes to the binary logging
+      mechanism.
+    </para>
+
   </section>
 
 </appendix>