Sponsored Link •
I began this article by contrasting systems that automatically enforce transactional semantics, such as database management systems and application servers, with Jini. From a distributed transaction system's viewpoint, these are transactional resource managers (TRM). If you implement a Jini service such that a DBMS or an application server manages all persistent data accessed under a Jini transaction, you can delegate lock management to that TRM.
Because TRMs manage much of the world's data, the Open Group, a technological consortium, developed the XA and XA+ standards, defining the interaction between a TRM and a transaction coordinator (see Resources for more information on these standards). Many commercial products, including DBMSs like Oracle or IBM's DB2, are TRMs that provide an XA interface. The
javax.transaction.xa package, a standard part of J2SE (Java 2 Platform, Standard Edition), allows an XA-compatible TRM to interact with Java components, including Jini services. That package's
XAResource interface defines methods for a resource to commit or abort (roll back) a transaction, and also facilitates steps of the two-phase commit protocol I described in Part 2.
While existing implementations of the Jini transaction coordinator don't directly allow an XA resource to enroll in a Jini transaction, you can implement a Jini service such that it integrates an XA transaction with a Jini transaction by mapping one to the other (perhaps using both transactions' unique IDs). Apart from this Jini-to-XA mapping, such a Jini service would not have to manage locks on objects, since that is then delegated to the XA resource.
Given that a variety of software systems -- including, lately, application servers -- expose XA-compatible interfaces, transactional interaction via this standard is becoming increasingly important. You could implement a Jini transaction coordinator so that it also enrolls XA resources in a transaction. That is an area ripe for progress in the Jini universe.
JavaSpaces are another resource manager that provides transactional access to objects. Their advantage is that they seamlessly integrate with Jini transactions. If you can manage data accessed by your transactions inside JavaSpaces, then you can delegate lock management on those objects to a JavaSpaces implementation. In a previous Jiniology article, Eric Freeman and Susanne Hupfer describe how you can enroll JavaSpaces in a Jini transaction.
Finally, although JDBC offers access to an underlying system's transaction mechanism, it does not directly support distributed transactions. If your Jini service stores its data in a DBMS that you access via JDBC, your DBMS won't be able to ensure transaction isolation during all phases of the two-phase commit protocol. While JDBC provides access to starting and committing a transaction inside a DBMS, it doesn't directly facilitate the prepared stage of a distributed transaction. Recall that when a participant votes
PREPARED in a Jini transaction, it guarantees that it can roll forward if it receives a subsequent
commit(), even if the service crashes during the transaction. Since JDBC does not facilitate this
PREPARED vote, your Jini service relying on JDBC to ensure a transaction's integrity and its associated data cannot offer this vote with confidence.