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 JTS The JTS version of the Banking application means that the Object Request Broker will be used. The ArjunaTS distribution is provided to works with JacOrb version 2.1 that can be obtained from the arjuna product page. Note: Ensure that the jacorb jar files are added in your CLASSPATH In a separate window launch the Recovery Manager, as follow.
>     java com.arjuna.ats.arjuna.recovery.RecoveryManager
Testing the distributed transaction with Implicit Propagation Context Start the Server java com.arjuna.demo.jts.remotebank.BankServer In a separate window, start the client java com.arjuna.demo.jts.remotebank.BankClient Testing the distributed transaction with Explicit Propagation Context Start the Server java com.arjuna.demo.jts.explicitremotebank.BankServer In a separate window, start the client java com.arjuna.demo.jts.explicitremotebank.BankClient In both cases (implicit and explicit), the Bank Server, which can be stopped by hand, displays the following lines: The bank server is now ready... In both cases (implicit and Explicit), the Bank Client window displays the following lines: ------------------------------------------------- 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 entering your choice, the appropriate operation is performed by the remote 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 in the server window a result that terminates with the following line [ Resource for Foo : Commit one phase ] Since only one AccountResource then only one CosTransaction.Resource 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 optimisation, indicated by the "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 in the client window "3" to make a transfer (300) from "Foo" to "Bar". Your choice : 3 - Make a transfer - ------------------- Take money from : Foo Put money to : Bar Transfer amount : 300 In the Server window you should see a result with the following lines [ Resource for Foo : Prepare ] [ Resource for Bar : Prepare ] [ Resource for Foo : Commit ] [ Resource for Bar : Commit ] Now two AccountResource objects, then two CosTransactions.Resource 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 - ---------------------------- Amount to withdraw : 200 Beginning a User transaction to withdraw from an account The requested account does not exist! ERROR - org.omg.CORBA.TRANSACTION_ROLLEDBACK: minor code: 50001 completed: No #### Using a stand-alone Transaction Server By default ArjunaTS does not use a separate transaction manager server: transaction managers are co-located with each application process to improve performance and improve application fault-tolerance. When running applications which require a separate transaction manager, you must set the com.arjuna.ats.jts.transactionManager property variable, in the arjunajts-properties.xml file, to YES. In a separate window, the stand-alone Transaction Server is launched as follow: java com.arjuna.ats.jts.TransactionServer [-test] The option -test allows to see the message "Ready" when the Transaction Server is started. The Banking application presented above gives the same output.
Running the example on several machines It is possible to run the Arjuna Transaction Service and recovery manager processes on a different machine and have clients access these centralized services in a hub-and-spoke style architecture. All that must be done is to provide the clients with enough information to contact the transaction service (such as the ORB's NameService). However, configuring the ORB is beyond the remit of this trailmap and so we shall opt for a simpler mechanism wherby the transaction services IOR is shared by access to a common file. This trailmap stage assumes that the transaction service has been appropriately installed and configured (the setenv.[bat|sh] script has been ran) onto two hosts (for the purpose of explanation we shall refer to these hosts as host1 and host2). Start the transaction service and recovery manager on host1 Start the recovery manager in one command prompt terminal java com.arjuna.ats.arjuna.recovery.RecoveryManager [-test] Start the transaction service in a second command prompt terminal java com.arjuna.ats.jts.TransactionServer [-test] Share the transaction service IOR on host1 with host2 Open a command prompt on host2 and copy the CosServices.cfg file from the <arjunajts_install_root>/etc directory on host1. For example, using the popular scp package, open a shell prompt and issue the following command: scp user@host1:<ats_root>/etc/CosServices.cfg <host2_ats_root>/etc/ Start the Bank Server and Bank Client applications on host2 NOTE: See the section above entitled "Using a stand-alone Transaction Server" for more information on how to configure these application to use a remote transaction service. Testing the distributed transaction with Implicit Propagation Context Start the Server
       java com.arjuna.demo.jts.remotebank.BankServer
In a separate window, start the client
       java com.arjuna.demo.jts.remotebank.BankClient
Testing the distributed transaction with Explicit Propagation Context Start the Server
       java com.arjuna.demo.jts.explicitremotebank.BankServer
In a separate window, start the client
       java com.arjuna.demo.jts.explicitremotebank.BankClient
Copyright 2002-2005 Arjuna Technologies All Rights Reserved. info@arjuna.com +44 191 243 0676