Check Out Objects

Problem

How can you maintain a lock on an object for a long period of time?

Context

You are developing a multi-user application that commits transactions on an application server. In your application, there is a substantial risk of a commit failure due to the probability of two clients modifying the same object during overlapping time intervals and you need to lock objects for an extended period of time.

Forces

Solution

Develop a lock table that holds persistent locks for objects that have been checked out. The application checks out a copy of the object, makes changes, and then checks in the changed copy.

Resulting Context

Since the application is making changes outside of a transaction, it will need to replay the changes within a server transaction. Also, the application must implement the lock table, which has its own concurrency issues.

Rationale

Application servers typically provide a locking mechanism within transactions. However, if updates need to be made during a long period of time, it is unreasonable to keep a transaction open while the changes are made. For example, if changes are made by an end user through a user interface, it is advisable for the changes to be specified outside of a transaction. In this case, the application must implement its own locking mechanism that will work across transactions.

Related Patterns

Replay Changes solves some of the problems in the resulting context set up by this pattern.