Enterprise Integration Patterns
Conversation Patterns
Conversation Patterns
LeaseConversation Patterns » Resource Management

A provider engages in long-running conversations with multiple partners. Each of these conversations requires the provider to allocate resources.

How can a service provider avoid holding resources for clients who are no longer interested?

Have the service provider issue a Lease to the resources. If not renewed, the lease will expire, allowing the provider to free allocated resources.

The Lease conversation involves the following participants:

Using a Lease the lease holder is always certain about the state of the resource. For example, if a Renew request fails (e.g. because the lease grantor is unreachable), the lease holder knows that the grantor will relinquish the lease. This conversation puts the burden for lease renewal on the lease holder.

A Renew message usually results in a new lease being issued and a new Lease message being sent. The conversation contract could also specify that the existing lease is renewed on the same terms as before, but an explicit Lease message simplifies the design of the Requestor and reduces coupling in the protocol as each interchange transmits the complete state. It also allows the Provider to re-adjust the lease duration, e.g. it can shorten the lease because it is short on resources.

The Requestor of the service is also referred to as the "holder" of the lease while the service is called the "grantor". The lease holder can actively cancel the lease before it is up to help the grantor release resources.

The lease holder can apply for a new lease before the existing one runs out.

The lease grantor can deny a Renew request. The Requestor may therefore be prepared to lose access to the resource. Whether such a denial is allowed should be specified in the conversation protocol as it places additional requirements on the Requestor.

Requestors may become over-eager in renewing leases, causing unnecessary network traffic and a potential strain on the Provider.

Lease relies on a shared clock between requestor and provider. In reality distributed systems are likely to use clocks that are slightly our of sync. If Lease durations are long, e.g. hours or days this likely does not matter. To be safe, the provider could add some extra "slack" after lease expiration before it actually de-allocates the resource.

See also: [POSA3].

Example: DHCP

The Dynamic Host Configuration protocol (DHCP) assigns IP addresses from a pool to requesting machines as a Lease. Machines have to renew their assigned IP address before the Lease expires. Otherwise, the server may reclaim it and assign it to a different machine. In many cases, clients receive the same address after renewal, but this is not guaranteed.

Creative Commons Attribution License

You can reuse the following elements under the Creative Commons Attribution license: pattern icon, pattern name, problem and solution statements (in bold), and the sketch. Other portions are protected by copyright.