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
Implementing the Account interface To take benefit from the persistency and locking mechanism provided by ArjunaCore, a user class can inherit from the appropriate class (StateManager for recovery, and LockManager for recovery and concurrency control). The AccountImpl class that implements the Account interface inherits the LockManager and implements the AccountOperations interface generated by the CORBA IDL compiler. Since multiple inheritance is not allowed in Java, inheriting the AccountPOA class, as made in simple jts remote version, in addition to the LockManager is not possible. That we use in this version a CORBA TIE mechanism to associate a servant to an CORBA object reference. The Java interface definition of the AccountImpl class is given below:
    public class AccountImpl
    extends LockManager implements AccountOperations
    {
      float _balance;
      String _name;
      public AccountImpl(String name );
      public AccountImpl(Uid uid);
      public void finalize ();
      public float balance();
      public void credit( float value );
      public void debit( float value );
      public boolean save_state (OutputObjectState os, int ObjectType);
      public boolean restore_state (InputObjectState os, int ObjectType);
      public String type();
    }
- Constructors and Destructor To use an existing persistent object requires the use of a special constructor that is required to take the Uid of the persistent object; the implementation of such a constructor is given below:
      public AccountImpl(Uid uid)
      {
        super(uid);
        // Invoking super will lead to invoke the
        //restore_state method of this AccountImpl class
      }
  There is no particular behaviour applied by the Constructor with the Uid parameter The following constructor is used for a new Account creation.
      public AccountImpl(String name )
      {
        super(ObjectType.ANDPERSISTENT);
        _name = name;
        _balance = 0;
      }
The destructor of the queue class is only required to call the terminate operation of LockManager.
    public void finalize ()
    {
      super.terminate();
    }
- save_state, restore_state and type The implementations of save_state and restore_state are relatively simple for this example:
      public boolean save_state (OutputObjectState os, int ObjectType)
      {
         if (!super.save_state(os, ObjectType))
            return false;

         try
         {
            os.packString(_name);
            os.packFloat(_balance);
            return true;
         }
         catch (Exception e)
         {
            return false;
         }
      }
      public boolean restore_state (InputObjectState os, int ObjectType)
      {
         if (!super.restore_state(os, ObjectType))
            return false;

         try
         {
           _name = os.unpackString();
           _balance = os.unpackFloat();
            return true;
         }
         catch (Exception e)
         {
            return false;
         }
      }
Because the AccountImpl class is derived from the LockManager class, the operation type should be:
    public String type ()
    {
      return "/StateManager/LockManager/BankingAccounts";
    }
- account management operations
      public float balance()
      {
        float result = 0;
        if (setlock(new Lock(LockMode.READ), 0) == LockResult.GRANTED)
        {
          result = _balance;
        }
        ...

        return result;
      }
  Since the balance operation consists only to get the current balance, acquiring a lock in READ mode is enough. This is not the case of the credit and debit methods that need to modify the current balance, that is a WRITE mode is needed.
      public void credit( float value )
      {
        if (setlock(new Lock(LockMode.WRITE), 0) == LockResult.GRANTED)
        {
          _balance += value;
        }
        ...
      }

      public void debit( float value )
      {
        if (setlock(new Lock(LockMode.WRITE), 0) == LockResult.GRANTED)
        {
          _balance -= value;
        }
        ...
      }
##### Sample Application Source Code Full source code for the AccountImpl class is included to provide you with a starting point for experimentation.
Copyright 2002-2005 Arjuna Technologies All Rights Reserved. info@arjuna.com +44 191 243 0676