www.arjuna.com news company products standards research library forums contact
Trail map 1. Installation Content 2. The Sample Application 3. Deploying and Testing the Sample Application 4. Making the Sample Application Persistent 5. Recovery From Failure 6. Where Next? Navigation Home Previous Additional Trails Distributed Transaction Processing The X/Open DTP Model The OMG OTS Model Transactions in J2EE Configuring ATS Configuring the Recovery Manager ORB Portability Transactional Object For Java
| print this page
| email this page
> Running The Banking application with JTA #### Configuring ATS Program Applications that create transactions using te JTA interface may invoke as well local services as remote services. When a remote invocation need to be performed, the current transactional context need to be propagated to the remote service in order to involve it to the transaction in progress. Arjuna Transaction Service allows the possibility to provide such feature using the facilities provided by JTS and ORB. More precisely ATS need to be configured to determine in which type of transaction, local or distributed, the JTA interface is used. #### Executing the JTA sample The Banking sample using JTA creates local transactions, ensure that JTA is configured for local transactions as explained above. To launch the JTA version of the Banking application, which creates only local transactions, execute the following java program:
>     java com.arjuna.demo.jta.localbank.BankClient
> Once one of the program given above is launched the following lines are displayed:
>     -------------------------------------------------
>       Bank client
>     -------------------------------------------------
>     Select an option :
>        0. Quit
>        1. Create a new account.
>        2. Get an account information.
>        3. Make a transfer.
>        4. Credit an account.
>        5. Withdraw from an account

>     Your choice :
> After introducing your choice, the appropriate operation is performed by the Bank object, to get the requested account, and by the account to execute the credit or withdraw or to return the current balance. Let's consider the following execution. Enter the number 1 as your choice, then give the name "Foo" as the account name and "1000" as an initial value of the account to create. You should get the following lines:
>     Your choice : 1
>     - Create a new account -
>     ------------------------
>     Name : Foo
>     Initial balance : 1000
>     Beginning a User transaction to create account
>     XA_START[]
>     Attempt to commit the account creation transaction
>     XA_END[]
>     XA_COMMIT (ONE_PHASE)[]
> The line XA_START indicates that the AccountResource object that implements the XAResource interface and enlisted to participate in the account creation transaction, receives the indication from the Transaction Manager that the transaction has started. The line XA_END indicates that the calling thread in which the AccountRessource object is associated shall be ended to enable the transaction completion as recommended by the X/Open specification. Since only one AccountResource then only one XAResource is involved in the account creation transaction, the two phases needed to get a consensus in the 2PC protocol are not mandatory. The one phase commit optimization, indicated by the "XA_COMMIT (ONE_PHASE)", is applied. In the same way create a second account with the name "Bar" and the initial balance set to 500. As a choice now, enter "3" to make a transfer (300) from "Foo" to "Bar".
>     Your choice : 3
>     - Make a transfer -
>     -------------------
>     Take money from : Foo
>     Put money to : Bar
>     Transfert amount : 300
>     Beginning a User transaction to get balance
>     XA_START[]
>     XA_START[]
>     XA_END[]
>     XA_PREPARE[]
>     XA_END[]
>     XA_PREPARE[]
>     XA_COMMIT[]
>     XA_COMMIT[]
> Now two AccountResource objects, then two XAResource objects are enlisted with the transaction. The displayed lines show that the two phases, prepare and commit, are applied. Any attempt to manipulate an account that it doesn't exist leads to throw the NotExistingAccount exception and to rollback the transaction in progress. For instance, let's withdraw money from an account FooBar not previously created.
>     Your choice : 5
>     - Withdraw from an Account -
>     ----------------------------
>     Give the Account name : FooBar
>     Amount to withdraw : 200
>     Beginning a User transaction to
>     withdraw from an account
>     The requested account does not exist!
>     ERROR - javax.transaction.RollbackException
Copyright 2002-2005 Arjuna Technologies All Rights Reserved. info@arjuna.com +44 191 243 0676