<?xml version="1.0"?>
<!--
  JBoss, Home of Professional Open Source
  Copyright 2006, JBoss Inc., and individual contributors as indicated
  by the @authors tag.  All rights reserved. 
  See the copyright.txt in the distribution for a full listing 
  of individual contributors.
  This copyrighted material is made available to anyone wishing to use,
  modify, copy, or redistribute it subject to the terms and conditions
  of the GNU General Public License, v. 2.0.
  This program is distributed in the hope that it will be useful, but WITHOUT A 
  WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A 
  PARTICULAR PURPOSE.  See the GNU General Public License for more details.
  You should have received a copy of the GNU General Public License,
  v. 2.0 along with this distribution; if not, write to the Free Software
  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, 
  MA  02110-1301, USA.
  
  (C) 2005-2006,
  @author JBoss Inc.
-->
<page title="Arjuna Technologies Limited: Trail map: Running and Testing Examples" rootpath="../..">
	<header>         Implementing the Account interface  </header>
	<content>
		<navigation>
			<links include="includes/www_arjuna_com_navigation.xml"/>
			<links include="includes/trailmap_navigation.xml"/>
			<links title="Navigation">
				<link ref="index.html">Home</link>
				<link ref="part6_txoj_banking_develop.html">Previous</link>
			</links>
			<links include="includes/trailmap_additional.xml"/>
		</navigation>
		<area title="Implementing the Account interface">
			<html>
				<p>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.</p>
<p>The Java interface definition of the AccountImpl class is given below:</p>
<pre>public class AccountImpl <strong>
<em>extends LockManager</em> implements AccountOperations</strong>
{
  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();
}</pre>
				<ul>
					<li>Constructors and Destructor 
    <p>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:</p>

<pre>public AccountImpl(Uid uid)
{
  super(uid); 
  // Invoking super will lead to invoke the 
  //restore_state method of this AccountImpl class
}</pre>
<p>There is no particular behaviour applied by the Constructor with the Uid parameter The following constructor is used for a new Account creation.</p>
<pre>
public AccountImpl(String name )
{
  super(ObjectType.ANDPERSISTENT);
  _name = name;
  _balance = 0;
}
</pre>

<p>The destructor of the queue class is only required to call the terminate operation of LockManager.</p>
	</li>

<pre>public void finalize ()
{
  super.terminate();
}
</pre>

	<li>save_state, restore_state and type 
    <p>The implementations of save_state and restore_state are relatively simple 
      for this example:</p>

<pre>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;
   }
}</pre>
<pre>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;
   }
} </pre>

<p>Because the AccountImpl class is derived from the LockManager class, the operation type should be:</p>
	</li>
<pre>public String type ()
{
  return &quot;/StateManager/LockManager/BankingAccounts&quot;;
}</pre>
	
	<li>account management operations 
  
<pre>public float balance()
{
  float result = 0;
  if (setlock(new Lock(LockMode.READ), 0) == LockResult.GRANTED)
  {
    result = _balance;
  }
  ...

  return result;
}</pre>

						<p> 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.</p>
<pre>
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;
  }
  ...
}</pre>
					</li>
				</ul>
				<h5>Sample Application Source Code</h5>
				<p>Full source code for the <a class="linkscoloured" href="../src/com/arjuna/demo/jts/txojbank/AccountImpl.java">AccountImpl</a> 
  class is included to provide you with a starting point for experimentation.</p>
			</html>
		</area>
	</content>
	<footer/>
</page>
