Reservation Service
The reservation service prevents users from simultaneously editing an object.
Use this service to restrict concurrent modification on an object by two or more users without employing the Check Out and Check In actions or other locking mechanism that modifies the object itself.
The reservation service consists of these primary components:
• A Windchill service that manages reservations for persisted objects.
• Client tools for adding reservation control to an edit window.
• Client tools for adding object update count control to an edit window.
Background
The reservation service was originally created to support concurrency control when editing change management objects (for example, problem reports, change requests, and change notices).
Change objects do not support the Check Out and Check In actions. As a result, it was possible for two users to simultaneously initiate the Edit action on the same object. When this happened, the system would save the updates of whichever user saved their changes first. The other user would receive an error message and lose all updates.
With the reservation service implemented, change objects are reserved for a single user as soon as they launch the Edit action. If another user attempts to edit the object, they are immediately presented with an error message similar to the following:
While originally created for change objects, the reservation service was designed as a general purpose tool that can be used for a variety of other concurrent modification scenarios.
Scope and Applicability
• Use the reservation service to manage concurrent updates of the same object by two or more users.
• The reservation service is limited to Windchill objects that implement the wt.reservation.Reservable interface.
• Site and organization administrators can release a reserved object for modification by a different user.
Limitations
• Objects are reserved for a user, not for a session or a thread. This allows for simultaneous modification of an object from multiple sessions or threads running for the same user.
• When using the reservation service, the following enforcements are made:
◦ Updates to a reserved object are detected and vetoed by a PersistenceManagerEvent.UPDATE listener.
◦ Deletions of a reserved object are detected and vetoed by a PersistenceManagerEvent.PRE_DELETE listener.
If this level of enforcement is not appropriate for your application, then the reservation service enforcement option should be disabled. Instead, you should create an application-specific service to provide the required enforcement.
• Objects are reserved for only a limited time and are released to allow modification by a different user when a reservation expires. The default is two hours. This time limit is controlled by the following property:
Name | ReservationService.expiresAfter |
Location | <Windchill>\codebase\wt.properties |
Default | 120 |
Synopsis | The number of minutes before a reservation expires. |
Description | A reservation is placed when a user modifies a non-version controlled object (for example, a change object). The reservation is held until the user completes their changes, cancels their changes, or a set amount of time has passed. This property controls the number of minutes until a reservation is automatically released. |
Intended Outcome
Prevent unintentional concurrent modifications of a reservable object by two or more users in a predictable and user-friendly manner.
For example, when a user attempts to edit a problem report that is already being edited by a user named “Jane Smith,” the following message appears:
When the user clicks OK, the message and edit window closes. The user can try again later.
As another example, if the user attempts to perform a Set State action on a problem report currently being edited by a user named “Jane Smith,” the following message appears:
The reservation service can also be used to prevent simultaneous modification of an object when no user interface is presented (for example, by another Windchill service).