Req't 3.4.9: Resource Locking / Transaction Model White Paper Version 1.0 1.0 Resource Locking: What is a resource? Resources can be physical things such as files or logical things such as versions of parts (some amount of data contained within a file). The important distinction to be made with respect to resource locking and the transaction model, is that I- DEAS transaction model maintains consistency based on transactions acted upon physical resources - i.e. files. How is a resource identified within I-DEAS? Resources are identified to the resource locking daemon by name. The name is constructed as one of three possible formats. The formats are defined by the type of lock that is requested. Physical resources are identified for transaction locks using the format (Installation:Project), or as a file compress lock using the format (pathname). I-DEAS identifies logical re- sources for in-use locks with the format (Installation:Project:Database:Version). The in-use lock represents a logical item contained within a physical resource and a transaction lock upon that physical resource will be required to complete a transaction. An in-use lock can also be placed on a project - a physical resource. Why are locks needed? Resource locks control access to information providing for concurrent access to information in a multi-user environment. Resource locking strategies attempt to maximize concurrency while preserving consistency of resources. Transactions can- not occur without a resource locking mechanism unless the environment is defined to be a single-user environment. What locks are used by I-DEAS? There are four kinds of locks in I-DEAS: transaction locks, in-use locks, persistent locks, and compressed locks. Trans- action locks can be further broken down into direct locks, queued locks, and hold locks. Transaction locks control access to physical resources. In-use locks control application behavior. Persistent locks which are set on projects (.pmd files) are configured, application-protected, inaccessible and invisible. Persistent locks which are set on item-versions within a project are protect, reserve, reference and import/export. Persistent locks are used for administrative control of persistent data. Compressed locks are used by I-DEAS to control access to files which have been compressed. Compressed locks serve the function of restricting access to a file until I-DEAS has successfully uncompressed that file. Locks (except for persistent locks) are always one of three base types: shared, update, or exclusive. What are hold locks? Hold locks are established in response to requests to modify a lock from one type to another type, if the modification re- quest cannot be immediately satisfied. The hold lock serves to prioritize the modification request such that it will be the next request which gets that lock when it becomes available. A hold lock takes priority over any lock request that was put into the queue. Hold locks do not modify locks, they simply enable future requests for a lock modification to succeed. Only one lock can be "held" on a resource. A hold lock prevents an update or shared lock from being set. The locking model - how are locks set? A resource can have zero or more direct locks, zero or more queued locks, and zero or one hold locks. An application can request locks in one of three ways. The direct request for lock either succeeds in placing the lock or fails. In-use locks are set using the direct request method. Another approach is to request the lock to be queued if unavailable through direct re- quest (this is the most common method). This approach places requests for locks into a queue to be processed based on the priority of the lock type - exclusive locks are granted before update locks which are granted before shared locks. Ap- plications must periodically attempt to set the lock again to see if the queued request can now be fulfilled. The queued approach is used to set transaction locks. The last method of acquiring a lock is a request to modify a lock into a lock of another type (i.e. change an update lock into an exclusive lock ). This method can be used directly, or can specify to "queue" the request through the hold lock mechanism. When is a direct request for a lock granted? A requested lock is granted if the resource does not already have a lock set, which would preclude the setting of the new requested lock. Rules for determining eligibility of setting locks are dependent on existing locks as well as both queued locks and a hold lock if present (Please see relevant sections below on queued and hold locks). Requests for shared locks are granted based on three conditions which must all be true. A shared lock request is granted if there is not an exclusive lock on the resource, and if there is not an exclusive lock in the queue for that resource, and there is not a hold lock on that resource. Requests for update locks are granted based on three conditions which must all be true. Requests for update locks are grant- ed if only shared locks are set for the resource, and only shared locks are in the queue for that resource, and there is not a hold lock on that resource. A hold lock prevents an update or a shared lock from being set. Requests for exclusive locks are granted if no other locks exist, and the queue is empty or the only entry in the queue, is the user's earlier request for this lock (allowing the request to be queued if it cannot be immediately performed). Hold locks do NOT prevent an exclusive lock from being set. Hold locks only affect the eligibility of setting share or update locks. How do queued locks affect the eligibility of setting a lock? The queue serves to keep track of requests for locks, ordered by the type of lock requested. New lock requests can always be placed into the queue, only direct requests for locks are affected by the queue. The hierarchy is defined such that : ? queued exclusive locks prevent any new direct locks from being set. ? queued update locks prevent any new direct locks except shared locks. ? queued shared locks prevent any new direct exclusive locks. How do hold locks affect the eligibility of setting a lock? Hold locks are set regardless of any queued locks that may exist. The presence or absence of queued locks does not affect the behavior of hold locks. In certain cases, the current state of the hold lock for the given resource is ignored in determin- ing eligibility of setting a hold lock. The four cases of lock modification are discussed below: If a shared lock is requested to be modified into an update lock, and the resource only has shared locks, and the resource either has no hold lock, or the user has the hold lock, the lock modification is made. If an update lock is requested to be modified to an exclusive lock, the lock will be granted if only one lock exists for the resource (the current update lock must be the only lock that exists). The state of the hold lock is not important in this case, as there can only be one update lock at any point in time. If the modification was allowed to be "queued", then a hold lock will be set if the modification request fails. If an update lock is requested to be modified into a shared lock, the request is always granted. If a hold lock was set by this user, it will be removed. A hold lock set by another user will not be removed. If an exclusive lock is requested to be modified into a shared lock, the request is always granted. If a hold lock exists, it will be removed, regardless of owner. 2.0 Transaction Model: How does the transaction model work? The transaction model is designed to provide optimum concurrency while maintaining consistency of the physical resourc- es. In the I-DEAS system, there are two kinds of transactions: read and write. Each read or write transaction is considered atomic and either completely succeeds or fails. The concept of multiple units of work (multiple write transactions) exists and is described in the section on multiple units of work. The transaction model is controlled through the use of transaction locks (Please see section on transaction locks below). A read transaction requests and sets a shared transaction lock and then performs the read operation. For the case of com- pressed files, the read transaction requires an exclusive transaction lock, as the physical file must be uncompressed to be used. The exclusive transaction lock is requested and set until the file is uncompressed. After the file is uncompressed, read transactions are performed which utilize the shared transaction lock (as previously explained). The write transaction starts by declaring intent to make a change by requesting and setting the update transaction lock. Once the update lock had been granted, the application prepares the information to be saved or changed. When ready to make the change, an exclusive transaction lock is requested and set on the physical resource. Only when the exclusive transaction lock is set, is the change actually committed to disk. What are transaction locks? There are three types of transaction locks: shared, update, and exclusive. The shared lock is used to perform read opera- tions upon a physical resource. Multiple shared locks may exist for the same physical resource. The update lock is used to declare an intent to change a physical resource, but does not allow for any changes to be made to the resou...
tuna8862