[jboss-svn-commits] JBL Code SVN: r37663 - in labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server: impl and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Mon Oct 24 10:43:09 EDT 2011
Author: tomjenkinson
Date: 2011-10-24 10:43:09 -0400 (Mon, 24 Oct 2011)
New Revision: 37663
Modified:
labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/LocalServer.java
labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/RemoteServer.java
labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/impl/ProxyXAResource.java
Log:
JBTM-895 updated the documentation
Modified: labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/LocalServer.java
===================================================================
--- labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/LocalServer.java 2011-10-24 13:45:05 UTC (rev 37662)
+++ labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/LocalServer.java 2011-10-24 14:43:09 UTC (rev 37663)
@@ -78,7 +78,7 @@
* here we have a hashmap to locate the transaction in.
*
* Clearly servers where the transaction has been inflowed back to *must
- * not* commit the transaction.
+ * not* commit the transaction.
*
* NOTE: CMT would not allow you do this anyway
*
@@ -104,6 +104,17 @@
* e.g. A transaction flowed 1,2,1 **must not** be committed at the third
* stage of the flow even though we are back at the originating server!!!
*
+ * When a transaction is propagated to a server the transport is responsible
+ * for detecting that the server has not participated in the transaction yet
+ * and if so it must assign it the next available subordinate name and
+ * persist this information to help with recovery (see ServerImpl.java and
+ * the test itself for how to determine the next available subordinate name
+ * and a potential method of persisting this data). This is important when a
+ * proxy xa resource is involved in recovery and invokes commit or rollback
+ * as the transaction must be reloaded by the remote server before the
+ * commit/rollback – if it was prepared - before we attempt to complete the
+ * transaction.
+ *
* @param remainingTimeout
* @param toImport
* @return
@@ -111,10 +122,10 @@
* @throws InvalidTransactionException
* @throws IllegalStateException
* @throws SystemException
- * @throws IOException
+ * @throws IOException
*/
- public boolean getAndResumeTransaction(int remainingTimeout, Xid toImport, Integer nextAvailableSubordinateName) throws XAException, InvalidTransactionException, IllegalStateException,
- SystemException, IOException;
+ public boolean getAndResumeTransaction(int remainingTimeout, Xid toImport, Integer nextAvailableSubordinateName) throws XAException,
+ InvalidTransactionException, IllegalStateException, SystemException, IOException;
/**
* Transport specific function to generate a proxy for a remote server.
Modified: labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/RemoteServer.java
===================================================================
--- labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/RemoteServer.java 2011-10-24 13:45:05 UTC (rev 37662)
+++ labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/RemoteServer.java 2011-10-24 14:43:09 UTC (rev 37663)
@@ -32,13 +32,10 @@
* classloader separation is used in
* <class>ExampelDistributedJTATestCase</class>
*
- * Most of the calls are fairly innocuous, however two need special explanation.
+ * Most of the calls are fairly innocuous, however one needs special explanation.
*
* Firstly the before completion takes an XID, check out
* <class>ProxySynchronization</class> for more details on that.
- *
- * More interesting is the propagate recover call - see it's Javadoc for
- * details.
*/
public interface RemoteServer {
Modified: labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/impl/ProxyXAResource.java
===================================================================
--- labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/impl/ProxyXAResource.java 2011-10-24 13:45:05 UTC (rev 37662)
+++ labs/jbosstm/branches/JBOSSTS_4_15_0_Final/atsintegration/examples/classes/com/arjuna/jta/distributed/example/server/impl/ProxyXAResource.java 2011-10-24 14:43:09 UTC (rev 37663)
@@ -44,37 +44,37 @@
* an XID that is allocated by the local transaction manager for this spoof XA
* resource.
*
- * This manifests itself in several ways, however most crucially when recover is
- * called. RemoteServer::recover returns the list of Xids to the proxy and the
- * proxy presents these to the coordinator (they are filtered at the remote
- * server so we know this server is responsible for the transaction). Before
- * they are returned however, the proxy gets them and replaces the remote view
- * of the XID for a locally known one.
+ * Persistence points required by the transport: ProxyXAResource: 1. Before a
+ * transaction is propagated the Xid must be recorded 2. When a transaction is
+ * successfully prepared the previously recorded Xid must be deleted and the
+ * real Xid recorded – otherwise the transaction could only be aborted with a
+ * heuristic The transport must register a *single* proxy XA resource per
+ * subordinate transaction – thereby eliminating diamonds in the users
+ * transaction flow. In my example I do this by registering the proxy xa
+ * resource after I have spoken to the remote server thereby allowing me to use
+ * knowledge from the remote server to determine whether or not a proxy is
+ * required. Do notice how the proxy xa resource is created before the
+ * transaction is flowed though, and the XID of the transaction is persisted to
+ * assist with recovery. Once the proxy xa resource is prepared, the file is
+ * then replaced and persisted again with the XID of the actual proxy xa
+ * resource. The first persist was just so that when recovering this proxy xa
+ * resource can be recovered so that we know we talked to a remote server for
+ * this transaction (and the remote server may have prepared the transaction,
+ * even if the parent failed before it was able to).
*
- * During recover, the proxy is checking through the list and replacing ones it
- * knows about with XIDs the local transaction manager knows about, any it
- * doesn't know about (due to failure) will not be replaced and therefore get
- * rolled back - as is right.
- *
- * This is actually one of the key points to be fair basically, the XID that the
- * remote server knows about, isn't directly one that the local server knows
- * about, the job of the proxy xa resource is to map the XIDs from the remote
- * back to locally known ones.
- *
- * As an example, an XID that this proxy might have been allocated would be:
- * <p>
- * gtrid UID, rootservernodename
- * <p>
- * bqual UID, parentservernodename, thisservernodename
- *
- * The remote view of this would be:
- * <p>
- * gtrid sameUID, sameRootservername
- * <p>
- * bqual sameUID, thisservernodename, remoteservernodename
- *
- * If we presented the XID from the remote server directly back to the local
- * server it would roll it back as it does not know about it.
+ * Recovery The proxy xa resource is responsible for recording which
+ * transactions are known of at the remote server and can therefore be recovered
+ * by it without requiring the proxy invoke the remote server to ascertain this
+ * list. When a transaction is propagated to a server the transport is
+ * responsible for detecting that the server has not participated in the
+ * transaction yet and if so it must assign it the next available subordinate
+ * name and persist this information to help with recovery (see ServerImpl.java
+ * and the test itself for how to determine the next available subordinate name
+ * and a potential method of persisting this data). This is important when a
+ * proxy xa resource is involved in recovery and invokes commit or rollback as
+ * the transaction must be reloaded by the remote server before the
+ * commit/rollback – if it was prepared - before we attempt to complete the
+ * transaction.
*/
public class ProxyXAResource implements XAResource {
@@ -196,7 +196,7 @@
e.printStackTrace();
throw new XAException(XAException.XA_RETRY);
}
-
+
System.out.println(" ProxyXAResource (" + localServerName + ":" + remoteServerName + ") XA_COMMITED");
if (map.get(xid) != null) {
More information about the jboss-svn-commits
mailing list