The Artima Developer Community
Sponsored Link

Survival of the Fittest Jini Services, Part II
Use Transactions to Coordinate the Reliable Interaction of Jini Services
by Frank Sommers
First Published in JavaWorld, July 2001

<<  Page 7 of 8  >>


Undecided Voters, Deadlocks, and Other Partial Failure Evils

Undecided voters are a problem not only for presidential candidates, but also for the 2PC protocol. When the transaction manager calls prepare() on a participant, it expects to receive a PREPARED, ABORT, or NOTCHANGED vote. However, distributed transaction messages must travel through the network, which is inherently unreliable. Thus, the transaction manager might never receive a vote from one or more participants. In addition, one or more of the services might crash during the transaction. For these reasons the 2PC protocol cannot completely guarantee a transaction's commitment (it's sometimes called a weak commitment protocol).

Jini solves the problem of weak commitment with leases. Because a Transaction is a leased resource in Jini, its lease sooner or later expires. When that happens, the transaction manager causes the transaction to abort, calling abort() on all participants it can still contact.

Orphaned transactions are those that are guaranteed to abort. When a participant has already returned a vote, and is waiting for the manager's call to commit() or abort(), it can inquire about the transaction's current state by calling getState() on the transaction. If the transaction replies PREPARED or COMMITTED, the participant can then commit the work done during the transaction. On the other hand, if the manager returns ABORTED, the participant must then exit the transaction by calling abort(). If it cannot contact the transaction manager for a while, then it might decide that the manager crashed, and abort the transaction as well.

When several participants in a transaction compete for the same resources, deadlocks might occur. Recall that during the transaction, all participants must ensure the transaction guarantees (ACID). For example, the transaction isolation requirement mandates that the credit card service should place a lock on the credit card account for the transaction's duration. During this time no other services can access the account. If several services inside that transaction need access to the credit card account, then they need to somehow coordinate their activities so they are not all waiting for each other.

Thus the problems of concurrency control are magnified by the service-oriented Web. The more services that interact on the Web this way, the more chances there are for serious deadlocks. Without lease expirations causing deadlocked Jini transactions to eventually abort, deadlocks could bring the whole service-oriented Web to a halt.

Figure 6. Deadlocked services

In the absance of a central concurrency-control mechanism, one way for transactions to avoid deadlocks is to relax the isolation level, allowing some changes to become visible outside the transaction while the transaction is still in progress. For instance, by being able to read the account balance, other services can possibly determine whether a charge on the account will succeed when they eventually receive a "write" lock on it. Many real-life transaction-processing systems operate with less than full isolation levels to achieve increased transaction throughput.

The data management community has developed an entire repertoire of techniques and tricks to deal with this and related issues. Transactional services teach us that, increasingly, data management problems are becoming problems of distributed computing, and, likewise, distributed computing problems are becoming those of data management. This realization invites us to pursue a more interdisciplinary approach so as to bring about better-informed solutions to these exciting challenges ahead of us.

<<  Page 7 of 8  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use