Sponsored Link •
For simpler Jini services, you might decide that an external transactional resource manager would be an overhead. Since many Jini services are implemented as activatable RMI (Remote Method Invocation) remote objects, I will conclude this article with an example of how such an object might manage a transaction's locks.
In this example, the
CreditCard service manages accounts in virtual memory, and accesses them via a
Map data structure. This data structure associates an account number with an object representing the account,
CCAcct, in turn, maintains a list of past purchases.
Here are the key objectives for this example:
This simple lock manager centers on a data structure that tracks the relationship between transactions, objects, and locks. In implementing 2PL, we aim to properly manage this data structure. In addition, we must guarantee the data structure's persistence and recovery in the event of service crashes.
net.jini.core.transaction.server.ServerTransaction class, an implementation of
Transaction, provides a unique transaction ID. We can use that ID as a key to unique transaction instances, and to map the objects those transactions access.
For allocating locks on objects, the JVM's monitor-based locks are not sufficient. Threads, not transactions, own monitor locks, and there is no necessary correspondence between Java threads and transactions. (Intuitively, you can imagine transactions as execution threads spanning not only virtual machines, but also possible VM restarts.) Therefore, in this example,
XLOCK objects represent shared and exclusive locks, respectively.
You can download the code for this simple example lock manager from the URL specified in Resources. Note, however, that the data structure managed in this example is relatively simple. With more complex data structures, lock management can become far more involved.