Transactions and Remote Objects

Transactions can be applied to remote objects. However, we have already discussed the benefits of separating business logic from infrastructure, so the remote object must be kept in the dark about the transaction. The transaction will be managed by the container. Consider the following series of images below in which we transfer the $100 from checking to savings in a remote object called Teller. Note that, in this case, the remote object does not have to know any of the details concerning the transaction. All it does is make individual requests to the database.

To emulate a business transaction, a program may need to perform several steps. A financial program, for example, might transfer funds from a checking account to a savings account, by performing the steps listed in the following pseudocode:

1. begin transaction
2. debit checking account
3. credit savings account
4. update history log
5. commit transaction

In the preceding pseudocode, the begin and commit statements mark boundaries of the transaction. To complete this transaction, all the three steps complete must complete successfully. If all three steps do not complete successfully, data integrity could be compromised.
This guarantee is described as atomicity. A transaction can end in two ways: with

1. a commit or
2. a rollback.

When a transaction commits, the modifications made by statements within the transaction boundaries are saved and made permanent. The changes are durable, that is they will survive future system failures. If any statement within a transaction fails, the transaction rolls back, undoing the effects of all statements executed so far in the transaction. In the pseudocode, for example, if a disk drive crashed during the credit step, the transaction would roll back and undo the data modifications made by the debit statement.
Even if a transaction fails, data integrity would be intact because the transaction accounts still balance. This aspect of transactional behavior is known as transactional consistency. The transaction service also provides isolation, which means that phases in a transaction cannot be observed by other applications and threads, until the transaction is committed or rolled back. Once a transaction is committed, the committed transaction can be safely observed by applications and threads.

The physical locations of remote objects and the clients that invoke them are not important. For example, it is possible for a client running in the same address space as a remote object to invoke a method on that object. It is also possible for a client across the Internet to do the same thing. To the remote object, both invocations appear to be the same. To make your object a remote object available to be invoked on by remote hosts, your remote class must perform one of the following steps:
Extend the class javax.rmi.PortableRemoteObject. PortableRemoteObject is a base class from which you can derive your remote objects. When your remote object is constructed, it automatically calls the PortableRemote Object's constructor, which makes the object available to be called remotely. Do not extend javax.rmi.PortableRemoteObject. Perhaps your remote object class needs to inherit implementation from another custom class. In this case, because Java does not allow for multiple implementation inheritance, you cannot extend PortableRemoteObject. If you do this, you must manually export your object so that it is available to be invoked on by remote hosts. To export your object, call javax.rmi.PortableRemoteObject.exportObject().
In the next lesson, you will be introduced to the deployment of a component in an Object Monitor.