[jboss-svn-commits] JBL Code SVN: r36215 - in labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US: extras and 1 other directory.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Sun Dec 5 21:11:58 EST 2010
Author: misty at redhat.com
Date: 2010-12-05 21:11:57 -0500 (Sun, 05 Dec 2010)
New Revision: 36215
Added:
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit.java
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_client_requests.java
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_commit.java
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit.java
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit_close.java
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/reliable_server.java
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/transactional_object.java
Modified:
labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/Constructing_An_OTS_Application.xml
Log:
Converted Constructing_An_OTS_Application.xml
Modified: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/Constructing_An_OTS_Application.xml
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/Constructing_An_OTS_Application.xml 2010-12-05 21:11:39 UTC (rev 36214)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/Constructing_An_OTS_Application.xml 2010-12-06 02:11:57 UTC (rev 36215)
@@ -4,6 +4,382 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-ArjunaJTS_Development_Guide-Test_Chapter">
- <title></title>
-</chapter>
-
+ <title>Constructing an OTS application</title>
+
+ <section>
+ <title>Important notes for JBossTS</title>
+ <section>
+ <title>Initialization</title>
+ <para>
+ JBossTS must be correctly initialized before you create any application object. To guarantee this, use the
+ <methodname>initORB</methodname> and <methodname>POA</methodname> methods described in the <citetitle>Orb
+ Portability Guide</citetitle>. Consult the <citetitle>Orb Portability Guide</citetitle> if you need direct use
+ of the <methodname>ORB_init</methodname> and <methodname>create_POA</methodname> methods provided by the
+ underlying ORB.
+ </para>
+ </section>
+ <section>
+ <title>Implicit context propagation and interposition</title>
+ <para>
+ If you need implicit context propagation and interposition, initialize JBossTS correctly before you create any
+ objects. You can only use implicit context propagation on an ORB which supports filters and interceptors, or the
+ <interfacename>CosTSPortability</interfacename> interface. You can set <varname>OTS_CONTEXT_PROP_MODE</varname>
+ to <literal>CONTEXT</literal> or <literal>INTERPOSITION</literal>, depending on which functionality you need. If
+ you are using the JBossTSA PI, you need to use interposition.
+ </para>
+ </section>
+ </section>
+
+ <section>
+ <title>Writing applications using the raw OTS interfaces</title>
+ <itemizedlist>
+ <title>Steps to participate in an OTS transaction</title>
+ <listitem>
+ <para>
+ Create <classname>Resource</classname> and <classname>SubtransactionAwareResource</classname> objects for each
+ object which will participate within the transaction or subtransaction. These resources manage the
+ persistence, concurrency control, and recovery for the object. The OTS invokes these objects during the
+ prepare, commit, or abort phase of the transaction or subtransaction, and the Resources perform the work of
+ the application.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Register <classname>Resource</classname> and <classname>SubtransactionAwareResource</classname> objects at the
+ correct time within the transaction, and ensure that the object is only registered once within a given
+ transaction. As part of registration, a <classname>Resource</classname> receives a reference to a
+ <classname>RecoveryCoordinator</classname>. This reference must be made persistent, so that the transaction
+ can recover in the event of a failure.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Correctly propagate resources such as locks to parent transactions and
+ <classname>SubtransactionAwareResource</classname> objects.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Drive the crash recovery for each resource which was participating within the transaction, in the event of a
+ failure.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The OTS does not provide any <classname>Resource</classname> implementations. You need to provide these
+ implementations. The interfaces defined within the OTS specification are too low-level for most
+ situations. JBossTS is designed to make use of raw <firstterm>Common Object Services (COS)</firstterm> interfaces,
+ but provides a higher-level API for building transactional applications and framework. This API automates much of
+ the work involved with participating in an OTS transaction.
+ </para>
+ </section>
+
+ <section>
+ <title>Transaction context management</title>
+ <para>
+ If you use implicit transaction propagation, ensure that appropriate objects support the
+ <interfacename>TransactionalObject</interfacename> interface. Otherwise, you need to pass the transaction contexts
+ as parameters to the relevant operations.
+ </para>
+
+ <section>
+ <title>A transaction originator: indirect and implicit</title>
+ <example>
+ <title>Indirect and implicit transaction originator</title>
+ <programlisting role="JAVA" language="Java"><xi:include href="extras/indirect_and_implicit.java"
+ xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <para>
+ A transaction originator uses indirect context management and implicit transaction
+ propagation. <classname>txn_crt</classname> is a pseudo object supporting the
+ <interfacename>Current</interfacename> interface. The client uses the <methodname>begin</methodname> operation
+ to start the transaction, which becomes implicitly associated with the originator’s thread of control.
+ </para>
+ <para>
+ The program commits the transaction associated with the client thread. The <systemitem>report_heuristics</systemitem> argument is set
+ to <literal>false</literal>, so the Transaction Service makes no reports about possible heuristic decisions.
+ </para>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/indirect_and_implicit_close.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ </section>
+
+ <section>
+ <title>Transaction originator: direct and explicit</title>
+
+ <example>
+ <title>Direct and explicit transaction originator</title>
+ <programlisting role="JAVA" language="Java"><xi:include href="extras/direct_and_explicit.java"
+ xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <para>
+ This transaction originator uses direct context management and explicit transaction propagation. The client
+ uses a factory object supporting the <interfacename>CosTransactions::TransactionFactory</interfacename>
+ interface to create a new transaction, and uses the returned <classname>Control</classname> object to retrieve
+ the <classname>Terminator</classname> and <classname>Coordinator</classname> objects.
+ </para>
+ <para>
+ The client issues requests, some of which involve transactional objects. This example uses explicit
+ propagation of the context. The <classname>Control</classname> object reference is passed as an explicit
+ parameter of the request. It is declared in the OMG IDL of the interface.
+ </para>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/direct_and_explicit_client_requests.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ <para>
+ The transaction originator uses the <classname>Terminator</classname> object to commit the transaction. The
+ <systemitem>report_heuristics</systemitem> argument is set to <literal>false</literal>, so the Transaction
+ Service makes no reports about possible heuristic decisions.
+ </para>
+ <programlisting language="Java" role="JAVA"><xi:include href="extras/direct_and_explicit_commit.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ </section>
+ </section>
+
+ <section>
+ <title>Implementing a transactional client</title>
+ <para>
+ The <methodname>commit</methodname> operation of <classname>Current</classname> or the
+ <interfacename>Terminator</interfacename> interface takes the <type>boolean</type>
+ <option>report_heuristics</option> parameter. If the <option>report_heuristics</option> argument is
+ <literal>false</literal>, the commit operation can complete as soon as the <classname>Coordinator</classname>
+ makes the decision to commit or roll back the transaction. The application does not need to wait for the
+ <classname>Coordinator</classname> to complete the commit protocol by informing all the participants of the
+ outcome of the transaction. This can significantly reduce the elapsed time for the commit operation, especially
+ where participant <classname>Resource</classname> objects are located on remote network nodes. However, no
+ heuristic conditions can be reported to the application in this case.
+ </para>
+ <para>
+ Using the <option>report_heuristics</option> option guarantees that the commit operation does not complete until
+ the <classname>Coordinator</classname> completes the commit protocol with all <classname>Resource</classname>
+ objects involved in the transaction. This guarantees that the application is informed of any non-atomic outcomes
+ of the transaction, through one of the exceptions <systemitem>HeuristicMixed</systemitem> or
+ <systemitem>HeuristicHazard</systemitem>. However, it increases the application-perceived elapsed time for the
+ commit operation.
+ </para>
+ </section>
+
+ <section>
+ <title>Implementing a recoverable server</title>
+ <para>
+ A Recoverable Server includes at least one transactional object and one resource object, each of which have
+ distinct responsibilities.
+ </para>
+
+ <section>
+ <title>Transactional object</title>
+ <para>
+ The transactional object implements the transactional object's operations<!--What??--> and registers a
+ <classname>Resource</classname> object with the <classname>Coordinator</classname>, so that the Recoverable
+ Server's resources, including any necessary recovery, can commit.
+ </para>
+ <para>
+ The <classname>Resource</classname> object identifies the involvement of the Recoverable Server in a particular
+ transaction. This requires a <classname>Resource</classname> object to only be registered in one transaction at
+ a time. Register a different <classname>Resource</classname> object for each transaction in which a recoverable
+ server is concurrently involved. A transactional object may receive multiple requests within the scope of a
+ single transaction. It only needs to register its involvement in the transaction once. The
+ <methodname>is_same_transaction</methodname> operation allows the transactional object to determine if the
+ transaction associated with the request is one in which the transactional object is already registered.
+ </para>
+ <para>
+ The <classname>hash_transaction</classname> operations allow the transactional object to reduce the number of
+ transaction comparisons it has to make. All <classname>Coordinators</classname> for the same transaction return
+ the same hash code. The <methodname>is_same_transaction</methodname> operation only needs to be called on
+ <classname>Coordinators</classname> with the same hash code as the <classname>Coordinator</classname> of the
+ current request.
+ </para>
+ </section>
+
+ <section>
+ <title>Resource object</title>
+ <para>
+ A <classname>Resource</classname> object participates in the completion of the transaction, updates the
+ resources of the Recoverable Server in accordance with the transaction outcome, and ensures termination of the
+ transaction, including across failures.
+ </para>
+ </section>
+
+ <section>
+ <title>Reliable servers</title>
+ <para>
+ A <firstterm>Reliable Server</firstterm> is a special case of a Recoverable Server. A Reliable Server can use
+ the same interface as a Recoverable Server to ensure application integrity for objects that do not have
+ recoverable state. In the case of a Reliable Server, the transactional object can register a
+ <classname>Resource</classname> object that replies <systemitem>VoteReadOnly</systemitem> to
+ <methodname>prepare</methodname> if its integrity constraints are satisfied. It replies
+ <systemitem>VoteRollback</systemitem> if it finds a problem. This approach allows the server to apply integrity
+ constraints which apply to the transaction as a whole, rather than to individual requests to the server.
+ </para>
+ </section>
+
+ <section>
+ <title>Examples</title>
+ <example>
+ <title>Reliable server</title>
+ <programlisting role="JAVA" language="Java"><xi:include href="extras/reliable_server.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+
+ <example>
+ <title>Transactional object</title>
+ <programlisting role="JAVA" language="Java"><xi:include href="extras/transactional_object.java" xmlns:xi="http://www.w3.org/2001/XInclude" parse="text" /></programlisting>
+ </example>
+ </section>
+ </section>
+
+ <section>
+ <title>Failure models</title>
+ <para>
+ The Transaction Service provides atomic outcomes for transactions in the presence of application, system or
+ communication failures. From the viewpoint of each user object role, two types of failure are relevant:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A local failure, which affects the object itself.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ An external failure, such as failure of another object or failure in the communication with an object.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The transaction originator and transactional server handle these failures in different ways.
+ </para>
+ <section>
+ <title>Transaction originator</title>
+ <variablelist>
+ <varlistentry>
+ <term>Local failure</term>
+ <listitem>
+ <para>
+ If a Transaction originator fails before the originator issues <systemitem>commit</systemitem>, the
+ transaction is rolled back. If the originator fails after issuing commit and before the outcome is
+ reported, the transaction can either commit or roll back, depending on timing. In this case, the
+ transaction completes without regard to the failure of the originator.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>External failure</term>
+ <listitem>
+ <para>
+ Any external failure which affects the transaction before the originator issues
+ <systemitem>commit</systemitem> causes the transaction to roll back. The standard exception
+ <systemitem>TransactionRolledBack</systemitem> is raised in the originator when it issues
+ <systemitem>commit</systemitem>.
+ </para>
+ <para>
+ If a failure occurs after commit and before the outcome is reported, the client may not be informed of the
+ outcome of the transaction. This depends on the nature of the failure, and the use of the
+ <option>report_heuristics</option> option of <systemitem>commit</systemitem>. For example, the transaction
+ outcome is not reported to the client if communication between the client and the
+ <classname>Coordinator</classname> fails.
+ </para>
+ <para>
+ A client can determine the outcome of the transaction by using method <methodname>get_status</methodname>
+ on the <classname>Coordinator</classname>. However, this is not reliable because it may return the status
+ <systemitem>NoTransaction</systemitem>, which is ambiguous. The transaction could have committed and been
+ forgotten, or it could have rolled back and been forgotten.
+ </para>
+ <para>
+ An originator is only guaranteed to know the transaction outcome in one of two ways.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ if its implementation includes a <classname>Resource</classname> object, so that it can participate in
+ the two-phase commit procedure.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The originator and <classname>Coordinator</classname> must be located in the same failure domain.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
+
+ <section>
+ <title>Transactional server</title>
+ <variablelist>
+ <varlistentry>
+ <term>Local failure</term>
+ <listitem>
+ <para>
+ If the Transactional Server fails, optional checks by a Transaction Service implementation may make the
+ transaction to roll back. Without such checks, whether the transaction rolls back depends on whether the
+ commit decision is already made, such as when an unchecked client invokes <systemitem>commit</systemitem>
+ before receiving all replies from servers.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>External failure</term>
+ <listitem>
+ <para>
+ Any external failure affecting the transaction during the execution of a Transactional Server causes the
+ transaction to be rolled back. If the failure occurs while the transactional object’s method is executing,
+ the failure has no effect on the execution of this method. The method may terminate normally, returning
+ the reply to its client. Eventually the <systemitem>TransactionRolledBack</systemitem> exception is
+ returned to a client issuing <systemitem>commit</systemitem>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Recoverable server</term>
+ <listitem>
+ <para>
+ Behavior of a recoverable server when failures occur is determined by the two phase commit protocol
+ between the <classname>Coordinator</classname> and the recoverable server’s
+ <classname>Resource</classname> object.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
+ </section>
+
+ <section>
+ <title>Summary</title>
+ <para>
+ When you develop OTS applications which use the raw OTS interfaces, be aware of the following items:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Create <classname>Resource</classname> and <classname>SubtransactionAwareResource</classname> objects for each
+ object which will participate within the transaction or subtransaction. These resources handle the
+ persistence, concurrency control, and recovery for the object. The OTS invokes these objects during the
+ prepare, commit, and abort phases of the transaction or subtransaction, and the
+ <classname>Resources</classname> then perform all appropriate work.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Register <classname>Resource</classname> and <classname>SubtransactionAwareResource</classname> objects at the
+ correct time within the transaction, and ensure that the object is only registered once within a given
+ transaction. As part of registration, a <classname>Resource</classname> receives a reference to a
+ <classname>RecoveryCoordinator</classname>, which must be made persistent so that recovery can occur in the
+ event of a failure.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ For nested transactions, make sure that any propagation of resources, such as locks to parent transactions,
+ are done correctly. You also need to manage propagation of <classname>SubtransactionAwareResource</classname>
+ objects to parents.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ in the event of failures, drive the crash recovery for each <classname>Resource</classname> which participates
+ within the transaction.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The OTS does not provide any <classname>Resource</classname> implementations.
+ </para>
+ </section>
+</chapter>
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,10 @@
+ ...
+ org.omg.CosTransactions.Control c;
+ org.omg.CosTransactions.Terminator t;
+ org.omg.CosTransactions.Coordinator co;
+ org.omg.CosTransactions.PropagationContext pgtx;
+
+ c = TFactory.create(0);
+ t = c.get_terminator();
+ pgtx = c.get_coordinator().get_txcontext();
+ ...
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_client_requests.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_client_requests.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_client_requests.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,2 @@
+ ...
+ transactional_object.do_operation(arg, pgtx);
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_commit.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_commit.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/direct_and_explicit_commit.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,2 @@
+ ...
+ t.commit(false);
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,8 @@
+ ...
+ txn_crt.begin();
+ // should test the exceptions that might be raised
+ ...
+ // the client issues requests, some of which involve
+ // transactional objects;
+ BankAccount1.makeDeposit(deposit);
+ ...
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit_close.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit_close.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/indirect_and_implicit_close.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,3 @@
+ ...
+ txn_crt.commit(false);
+ ...
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/reliable_server.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/reliable_server.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/reliable_server.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,44 @@
+/*
+ BankAccount1 is an object with internal resources. It inherits from both the TransactionalObject and the Resource interfaces:
+*/
+interface BankAccount1:
+ CosTransactions::TransactionalObject, CosTransactions::Resource
+{
+ ...
+ void makeDeposit (in float amt);
+ ...
+};
+/* The corresponding Java class is: */
+public class BankAccount1
+{
+public void makeDeposit(float amt);
+ ...
+};
+/*
+ Upon entering, the context of the transaction is implicitly associated with the object’s thread. The pseudo object
+ supporting the Current interface is used to retrieve the Coordinator object associated with the transaction.
+*/
+void makeDeposit (float amt)
+{
+ org.omg.CosTransactions.Control c;
+ org.omg.CosTransactions.Coordinator co;
+ c = txn_crt.get_control();
+ co = c.get_coordinator();
+ ...
+/*
+ Before registering the resource the object should check whether it has already been registered for the same
+ transaction. This is done using the hash_transaction and is_same_transaction operations. that this object registers
+ itself as a resource. This imposes the restriction that the object may only be involved in one transaction at a
+ time. This is not the recommended way for recoverable objects to participate within transactions, and is only used as an
+ example. If more parallelism is required, separate resource objects should be registered for involvement in the same
+ transaction.
+*/
+ RecoveryCoordinator r;
+ r = co.register_resource(this);
+
+ // performs some transactional activity locally
+ balance = balance + f;
+ num_transactions++;
+ ...
+ // end of transactional operation
+};
\ No newline at end of file
Added: labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/transactional_object.java
===================================================================
--- labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/transactional_object.java (rev 0)
+++ labs/jbosstm/trunk/ArjunaJTS/docs/ArjunaJTS_Development_Guide/en-US/extras/transactional_object.java 2010-12-06 02:11:57 UTC (rev 36215)
@@ -0,0 +1,25 @@
+/* A BankAccount2 is an object with external resources that inherits from the TransactionalObject interface: */
+interface BankAccount2: CosTransactions::TransactionalObject
+{
+ ...
+ void makeDeposit(in float amt);
+ ...
+};
+
+public class BankAccount2
+{
+public void makeDeposit(float amt);
+ ...
+}
+/*
+Upon entering, the context of the transaction is implicitly associated with the object’s thread. The makeDeposit
+operation performs some transactional requests on external, recoverable servers. The objects res1 and res2 are
+recoverable objects. The current transaction context is implicitly propagated to these objects.
+*/
+void makeDeposit(float amt)
+{
+ balance = res1.get_balance(amt);
+ balance = balance + amt;
+ res1.set_balance(balance);
+ res2.increment_num_transactions();
+} // end of transactional operation
\ No newline at end of file
More information about the jboss-svn-commits
mailing list