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?
- A Lease allows the provider to set the length of the resource allocation at the time of the request but it has no means to shorten or rescind allocations for example when it experiences a shortage of resources. In such a case it can only reject new requestors.
- A Lease requires the lease holder to actively monitor the duration of the lease to renew in time. This might be cumbersome for some clients.
- In ditributed systems clocks may get out of sync, causing a lease holder to believe the lease is still valid, while the lease grantor already expired the lease.
Have the provider periodically check whether the requestor still requires the resource. If the requestor answers "no" or is unreachable, the provider relinquishes the resource.
The Renewal Reminder conversation involves the following participants:
- The Requestor initiates the conversation by Requesting a resource. In return he receives a message containing a Reference to the allocated resource. Periodically, the Requestor receives a Ping from the provider. In order to retain the resource it must Confirm the ping.
- The Provider accepts Request messages for resources and grants them if resources are available, returning the Reference to the resource. Periodically, or when resources are tight, the Provider sends a Ping to one or more Requestors. It expects to receive a Confirm message in order to retain the resource.
Renewal Reminder consists of multiple Asynchronous Request-Response conversations, one initiated by the Requestor and recurring instances initiated by the Provider. For both occasions, the participants may use Request-Response with Retry. Especially for the Ping message, through, retry counts will be low as its purpose is to detect unresponsive Requestors.
Renewal Reminder gives the provider more control but also burdens it with more house keeping. In the flip side the consumer can be simpler as it does not have to track the expiration of the lease or initiate renewals. It does, however have to be able to respond to incoming request messages to process the Ping message.
If resources are plentiful, this conversation can result in very low traffic as the provider will have little need to ping requestors. As the provider gets into a space crunch it can react by pinging, hoping that some clients are no longer present or no longer need their resource.
If a client is unreachable, the Provider can decide to retry the request or relinquish the resource on the spot. This can leave provider and consumer in an inconsistent state: the consumer, not aware that the provider tried to contact it, might be under the impression that the resource is still available whereas the provider has already cancelled it.
Generally, Renewal Reminder exhibits more coupling between participants than
Example: Magazine Subscription
In this case the provider is eager to have the requestor renew the resource because it is paid. It uses the Renewal Reminder conversation but with a Request-Response with Retry conversation for the Ping with often an (annoyingly) high retry count.
Related patterns: Lease, Asynchronous Request-Response, Request-Response with Retry
