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.