[jboss-svn-commits] JBL Code SVN: r23493 - labs/jbosstm/trunk/XTS/docs.

[jboss-svn-commits at lists.jboss.org]

Author: adinn
Date: 2008-10-17 08:06:30 -0400 (Fri, 17 Oct 2008)
New Revision: 23493

Modified:
   labs/jbosstm/trunk/XTS/docs/XTSBARecoveryNotes.odt
   labs/jbosstm/trunk/XTS/docs/XTSBARecoveryNotes.pdf
   labs/jbosstm/trunk/XTS/docs/XTSRecoveryNotes.txt
Log:
corrected some details of recovery process

Modified: labs/jbosstm/trunk/XTS/docs/XTSBARecoveryNotes.odt
===================================================================
(Binary files differ)

Modified: labs/jbosstm/trunk/XTS/docs/XTSBARecoveryNotes.pdf
===================================================================
(Binary files differ)

Modified: labs/jbosstm/trunk/XTS/docs/XTSRecoveryNotes.txt
===================================================================
--- labs/jbosstm/trunk/XTS/docs/XTSRecoveryNotes.txt	2008-10-17 12:05:07 UTC (rev 23492)
+++ labs/jbosstm/trunk/XTS/docs/XTSRecoveryNotes.txt	2008-10-17 12:06:30 UTC (rev 23493)
@@ -285,11 +285,13 @@
 participant record type (akin to the ACCoordinator type used on the
 coordinator side to store XTS WS-AT coordinator (transaction)
 state). WS-AT participant recovery records differ from other object
-store entries in that they are not derived from AtopmicAction nor from
-StateManager. The former class is only appropriate as a superclass of
-transactions. The latter class is only appropriate as a superclass of
-classes which will be saved and restored when an Action is current in
-the saving/restoring thread context and that is not the case in the
+store entries in that they are not derived from AbstractRecord nor
+from StateManager. The former class is only appropriate where the
+record is capable of being driven through prepare, commit and/or abort
+by a BasicAction, which is only appropriate on the coordinator
+side. The latter class is only appropriate as a superclass of classes
+which will be saved and restored when an Action is current in the
+saving/restoring thread context and that is not the case in the
 threads which handle Participant service incoming messages (*** is
 this actually correct -- need to check ***). Note, however, that this
 should present no problem in managing the object store entries in the