Advertisement

Summary
The Jini Transaction Specification defines a transaction coordinator for the two-phase commit protocol, as well as a default transaction semantics guaranteeing ACID properties. This article explains the default transaction semantics, and offers guidelines for its implementation in services based on activatable RMI objects.

In my last Jiniology article, I described distributed transactions that enable multiple Jini services to reliably coordinate their work to support a common objective: When services enroll in a transaction, they guarantee that any outcome agrees with a set of conditions, or invariables.

For example, an online bookstore, implemented as a Jini service, uses a credit card service for payment processing. By enrolling the credit card service in a transaction, a purchase guarantees that either the credit card is charged and the book ships, or that neither action takes place.

A transaction promises certain computation invariables that define the transaction's semantics. Jini lets you implement any transaction semantics. You can decide what guarantees cooperating services must provide, and implement your services according to those guarantees.

Regardless of specific invariables, you can use the Jini transaction coordinator to arrange your transaction's commitment, employing the two-phase commit protocol. In Part 2 of this series, I described how you use that coordinator as a client for the two-phase commit protocol. In this article, I will focus on techniques for writing transaction participant Jini services.

Read the whole "Survival of the Fittest Jini Services" series:

• Part 1. Ensure the quality of Web services in the age of calm computing
• Part 2. Use transactions to coordinate the reliable interaction of Jini services
• Part 3. Implement transactional Jini services