Leases, transactions, and distributed event mechanisms in distributed programming patterns

The characteristics of Jini technology oriented to network and distributed computing determine the difference between the Jini technology and the traditional stand-alone system in many aspects, which are conceptually and practically applied. such as network delay, failure, or sudden withdrawal of equipment, will result in disorder and loss of information, the acquisition, preservation, maintenance and recovery of resources are more complex, the reliability and efficiency of communication and coordination between different entities are not as easily guaranteed as in stand-alone systems. As a result, the distributed programming model is added to Java in Jini, especially the introduction of leases, distributed transactions and distributed events.

Lease

The basic concept of leases is that resources can only be used for a period of time, as agreed by the holder of the lease (lease holder) and the authorized person (lease grantor) of the lease.

The goal of the lease interface is to provide a special programming style for distributed systems and applications. This programming style is when an object accesses the resource for the first time, the two objects negotiate first, and finally authorize the use of the resource for a certain period of time.

In a non-distributed system, a resource or service is authorized to be explicitly released or discarded, a programming pattern that is doomed to fail in a distributed system because it is not guaranteed to discard the use of resources or systems, which will cause this part of the system's resources to never be released.

The concept of leases was introduced to avoid such problems. The authorization of a resource or service leased in a lease is based on time. Once the lease expires, the service will end and the resources will be released. The term of the lease is determined at the first authorization and is negotiated in request/response manner by the authorized person and receiver of the lease. Leases may be renewed or cancelled before expiry. Upon expiry, both parties consider that the services or resources have been recovered.

The introduction of lease concepts can also be used to solve another problem faced by distributed systems. The conventional way to solve this problem is to have the task of cleaning up useless resources as a system administrator by tending to accumulate outdated and unnecessary information. However, when this resource is leased, there is no accumulation of outdated information and no need for manual removal. The leased information or resources are only saved on the system when the lease is renewed. Therefore, the forgotten information will be deleted after a limited time.

The Jini system defines a set of interfaces and related conventions and protocols to enable different Java virtual machines to negotiate the use of leases for various resources. Leases can be formed in a variety of agreements, including access to an object (reference) agreement, the Future Action (event notification) Agreement and the provision of long-term storage agreements. The lease mechanism should be combined with the concurrency mechanism, that is, a resource can have multiple concurrent lease holders.

The characteristics of the lease include: the authorized person ensures that the holder is able to access the resource over a period of time, and within the term of the lease, the holder of the tenancy may cancel the lease, the authorized person will clear the relevant resources, the holder may request a renewal, and the renewal period shall be decided by both parties; Unlike the cancellation of leases, there is no need for communication between the authorized person and the holder.

Transaction

Transactional behavior is particularly important in distributed computing, which provides a way to keep one or more remote participants consistent with the results of a series of operations. The Jini system implements transaction semantics to the individual objects in the transaction. The first thing the system provides is a cooperative mechanism for exchanging information between objects in order to provide a minimum set of protocols and interfaces for the object to implement transactional semantics.

The completion protocol described by Jini consists of a two-phase commit protocol of a distributed system. The two-phase commit protocol defines the communication mode of the Distributed object resource, which requires a manager to ensure the consistency of the operation set resolution, that is, to ensure that all participants finally know whether they should commit or discard the operation.

A transaction is created and supervised by a manager, and each transaction is represented by an identity, which is unique to the manager of the transaction. A client creates a transaction through a request to a manager, and often makes a semantic object known as the Transactionfactory. This semantic object is passed as a parameter when an operation is carried out on a service. If the service agrees to accept this transaction and manages its operations, it must join the transaction as a participant.

If a transaction is committed successfully, all operations performed under the transaction are completed. Abandoning a transaction means that all operations performed under a transaction are as if they had not happened at all. Submitting a transaction requires each participant to "vote", the vote can choose "Ready" (ready to submit), "unchanged" (read only), or "Give up" (the transaction should be discarded).

The two-phase commit protocol is designed to enable an object to provide ACID properties. The default transaction semantics defines one way to retain these properties. The ACID properties are:

· Atomicity (atomization): All operations under one transaction occur or none occurs.

· Consistency (consistency): the completion of a transaction must keep the system in a consistent state. A transaction is only a tool that makes it possible to ensure consistency, and it is not a guarantor of consistency in itself.

· Isolation (Isolation): The transactions being performed should not affect each other. A participant of a transaction should see only the middle state of the operation in its own transaction, not the middle state of the other transaction.

· Durability (Durability): The result of a transaction submission should be as persistent as the object entity that the transaction commits, but this guarantee can only be done by the object.

Relying on participants to implement ACID properties is the biggest difference between a two-phase commit protocol and a traditional transaction processing system. The two-phase commit protocol is defined using three main types:

· transactionmanager--the transaction manager to create a new transaction and coordinate the participants ' actions.

· nestabletransactionmanager--Some transaction managers are able to support nested transactions.

· transactionparticipant--when an operation is performed under a transaction, the participant must join the transaction, giving the manager a reference to the Transactonparticipant object to be used for the vote.