Method for non-hierarchical lock management in a multi-system shared data environment5551046Abstract In a combination of multiple concurrently-executing database management systems which share data storage resources, efficient lock processing for shared data is implemented by hiding from a global lock manager the distinction between transaction-interest and cache-interest locks that are processed at the DBMS level. The local lock manager of a DBMS, in response to a request for either type of lock, may issue a request to the global lock manager for a system-level lock without disclosing to the global lock manager the type of lock requested of the local lock manager. After receipt of the system level lock, the local lock manager can grant either transaction or cache interest locks locally on a data resource if the combined mode of locally-held locks on that data resource is greater than or equal to the requested mode. Claims We claim: Description BACKGROUND OF INVENTION
TABLE I
______________________________________
Resultant Mode
No. L lock P lock of L and P locks
______________________________________
1 Null Null Null
2 Null S S
3 Null X X
4 S Null S
5 S S S
6 S X X
7 X Null X
8 X S X
9 X X X
______________________________________
THE INVENTION The invention concerns a technique to save messages for transaction locking and cache coherency in a multiple DBMS environment with shared data storage such as that illustrated in FIG. 2. Typically, transaction locking provides serialization to preserve transaction semantics in a multi-system environment. The locking function requires coordination among multiple DBMS's which is done by message exchange between the global lock manager and the local lock managers. The cache manager of a DBMS follows cache coherency protocols to ensure that the DBMS instance in which it is included always uses the current copy of data. Cache coherency protocols also use locking. These protocols depend on whether the DBMS follows a "no-force-at-commit" or a "force-at-commit" policy in the multi-system environment. In this regard, the force-at-commit policy means that an updated data resource will be returned to ("forced to") DASD when the updating transactions commits. In contrast, no-force-at-commit policy does not require that the updated data object be returned to DASD as a condition of committing the updating transaction. Rather, the updated data resource may dwell in a cache after the updating transaction commits. However, this policy does require some means for signalling to other potential using systems that a particular cache location contains a version of a data resource which is more current than that in the shared data storage resource (DASD). A primary and overiding thrust of a multi-system with shared data such as that illustrated in FIG. 2 is to reduce the number of lock and unlock calls which result in messages to the global lock manager for transaction locking and cache coherency. The technique of the invention, called LP locking, saves locking calls when the unit of ownership of the data resource by a transaction is the same as the unit of caching that resource by the cache manager. The local lock manager can hide the distinction between the L-type lock which is issued to serve a transaction interest and the P-type lock which is issued on the same data resource for cache ownership. The L and P locks for the data resource, although distinct to a local lock manager are known in the invention as a single lock--an LP lock--by the global lock manager. The global lock manager knows only that the owner of the LP lock is a local lock manager and that the lock mode is the resultant mode of all L and P locks maintained by the owning local lock manager of the data resource. A local lock manager can grant an L or P lock on a data resource locally if the combined lock mode of the L and P locks held on the same data resource is equal to or higher than the requested mode. Also, a local lock manager can suppress the unlock call of an L (or a P) lock to the global lock manager if the P (or the L) lock is still held in the same or higher lock mode. This saves the lock and unlock calls from a local lock manager to the global lock manager, thereby saving messages between them. It is assumed in this invention, that the global and local lock managers communicate by way of some efficient message procedure, for example, by message batching. However, all messages have processing overhead, and batching increases latency. Both processing overhead and latency impact transaction lock hold time and response time. Therefore, the optimization to save lock and unlock calls to the global lock manager is an important performance attribute of the invention. Importantly, L and P locks on a data resource cannot be treated as hierarchical locks since the order of their acquisition is unpredictable. For example, when a cache manager prefetches pages prior to transaction usage of those pages to improve I/O performance for sequential scan of data, the P locks on those pages would be acquired before the L locks are acquired; for a typical random access of data by a transaction, the L lock on a page would be acquired before the P lock is acquired, assuming the page is not already cached. THE L LOCK A transaction obtains ownership of a data resource by way of a logical (L) lock. Hereinafter, it is assumed that the data resource is a page in a database. However, the inventors contemplate that transaction interest may be expressed in other database units. In requesting a lock, the transaction provides the name of the page being locked as the lock name, the type of lock, which for a transaction, is an L lock, the mode necessary to implement a contemplated operation, and identification of the transaction or process which will own the requested lock. In the following discussion, it is assumed that the transaction acquires an L lock in either the shared (S) mode to read a page or in the exclusive (X) mode to update a page. This is for simplicity of the explanation and is not intended to limit the practice of the invention to a dual-mode locking scheme. Compatability rules for S and X-mode locks are as follows: If a lock is held in S mode and an S mode is subsequently requested by another transaction, the subsequent request is compatible; if an S mode is requested and an X-mode lock is held, the subsequent request is incompatible and the requesting transaction will be placed in a wait state until the holder unlocks the data resource by surrendering or downgrading its lock. When a lock is held, a subsequent request for an X-mode lock is considered incompatible, no matter what the mode of the held lock is. The compatability of lock modes is contrasted with the concept of resultant lock mode discussed above which is a mode value derived by a local lock manager from the lock modes of locks held on a data resource for which a lock has been requested. Particularly, if a transaction requests a DBMS to grant a lock on a data resource, which is already held in the DBMS and the requested mode is less than or equal to the resultant lock mode, it is possible for the local lock manager to save a lock call to the global lock manager by granting the lock locally. This is because the global lock manager already "knows about" the lock. In this regard, if the transaction requests an S-mode lock on a data resource which is already L locked, the local lock manager will compute the resultant mode of the held locks as S if no held lock has a magnitude exceeding S. If an X-mode lock is held, the resultant lock mode is deemed to be X. THE P LOCK The cache manager in a DBMS which caches a page obtains cache ownership of a page via a P lock. It is observed that the P lock is a different type lock than the L lock because the purpose of its ownership is different. For example, a P lock requested in exclusive mode in the system should not conflict with the L locks for the same data resource on that system. The P lock is acquired to ensure cache coherency between systems and the L locks are acquired for intra- and inter-system isolation and serialization of transaction access to a resource. In the invention, the distinction between L and P locks is kept only at a local lock manager level and the global lock manager is unaware of this distintion. In providing a P lock request to the local lock manager, the cache manager specifies the lock name of the page which is being, together with a lock name extension which makes it different from the L lock name for the same page, the lock type, the lock mode, and cache-manager-identification for this system. The cache manager must acquire a P lock for a page before it caches that page in the cache for DBMS. The P lock is held for so long as the page is cached, implying that when different transactions use a page already in the system they do not pay the overhead of acquiring the P lock. The cache manager acquires the P lock in share mode when a page is to be read, and in exclusive mode when the page is to be updated. The compatability rules for the P lock are the same as for the L lock, with the sole distinction that they apply only between DBMS's, there being only one P lock which is owned by the cache manager of any DBMS. COHERENCY PROTOCOL FOR NO-FORCE-AT-COMMIT IN A PRIOR ART SYSTEM A cache- or buffer-interest lock is typically used to support coherency of a changed page in a system environment such as that illustrated in FIG. 2 where multiple DBMS's have respective caches and each DBMS uses a no-force-at-commit policy. In this regard, a cache manager always acquires a P lock when it caches a page in its DBMS. In the prior art hierarchical locking system, a DBMS must acquire a P lock in a certain mode before it can issue L locks on the identified data resource. Under the hierarchical arrangement, the P lock call is communicated to an interest manager. The interest manager knows from its table which system(s) hold the lock and therefore have buffered that page. If the P lock is held in share mode, the page can be buffered in multiple systems, if in exclusive mode, the page can be buffered in only one system. For the latter case, the interest manager's directory entry would provide the identification of the system which has the changed page cached. Next is given an example of how the prior art system might employ a P lock coherency scheme under a no-force-at-commit policy. Assume that a DBMS S1 has page A buffered as a changed page. Therefore, the interest manager's lock table entry would show that the resource lock manager of S1 holds the P lock on page A in state X. Also assume that the transaction which has updated page A has committed. In this case, page A will not necessarily have been written to DASD as the DBMS is implementing a no-force-at-commit policy. Now, the transaction in the second DBMS S2 needs to read page A. An L lock would be requested on page A in the share state, eliciting a P lock request from system S2 to the interest lock manager in the share state. The interest manager would detect the lock conflict and send a message to the resource lock manager in S1 informing it of the lock conflict for page A by another system. The resource manager in system S1 would do the following processing for the P lock request: It would invoke its buffer manager's lock-conflict routine with the following parameters: (a) lock name of the page for which the conflict occurred, i.e., page A, (b) the requested lock mode, i.e., S, and (c) the identification S2 of the requesting system. The buffer manager of system S1 would resolve the P lock conflict by writing the page to DASD (if the versions differ) and sending the page by way of a communication link to system S2. Following completion of the DASD I/O, the buffer manager could request its resource lock manager to change its P lock mode to S, which would continue to buffer page A in S1's buffer. The resource lock manager in S1 would pass the new P lock mode for page A to the interest manager. The interest manager would update its directory to note that DBMS S1 holds the P lock on page A in the S mode and would grant the P lock in S mode to the DBMS S2. Thus, the current copy of changed page A and S1 is propagated to S2 and S1 follows a no-force-at-commit policy. This maintains the coherency of a changed page in a multiple DBMS environment by way of hierarchical P locking when all DBMS's follow a no-force-at-commit policy. Therefore, it will be appreciated that use of the hierarchical locking scheme of the prior art would constrain a DBMS to first possess a P lock on a data resource before granting L locks on the data resource. Thus, L lock requests for unbuffered pages would have to be suspended while the resource lock manager engages in a P lock request/grant process with the interest manager. LP LOCKING In invention, LP locking is used to invest a local lock manager with the power to issue locks locally. Thus, a local lock manager is empowered to engage in a request/grant exchange with the global lock manager in response to the first lock request for an uncached data resource without regard to whether the request is for an L or P lock. The ownership distinction between L and P locks is important only for the local lock manager; the global lock manager is interested in lock ownership only at the local lock management level. Therefore, if an L lock request is received for a page which is not cached, the local lock manager can request an LP lock from the global locking manager, anticipating that a P lock request will follow from its own cache manager. Further, if an L lock is already held on a page and a P lock request is made for the same page and in a mode which is less than or equal to the resultant mode of the existing L lock, the local lock manager can grant the P lock without communicating with global lock manager. The resultant mode of the L and P locks is determined by the lock modes in which they are held by the transactions and the cache manager of the "owning" DBMS. Thus, a local lock manager hides the distinction between the L and P locks for the same data resource from the global lock manager. Although distinct at the local level, the distinction between L and P locks is blurred at the global level where they are merged into a single LP lock. The global lock manager knows the owner and mode of the LP lock. The invention permits a local lock manager to grant an L lock on a page locally if the resultant mode of L and P locks held on the page is greater than the requested mode according to the magnitude relationship given above. The same is the case when the P lock is requested. OPERATION OF THE INVENTION With reference to Table I and to FIGS. 2-4, the operation of the invention in responding to an L lock request will next be described. Assume that a local lock manager such as 36 perceives a lock request from the transaction 49. A request 100 is made in the form of a procedure call to the local lock manager. The logic of the local lock manager responds according to the invention by taking a first decision 102 wherein the local lock manager inspects its lock table to determine whether the name of the L lock is known. Assume that no L lock for the page named in the lock request is in the table. The negative exit will be taken from decision 102 and a table entry corresponding to the entry 82 will be made and entered into the local lock table 80. Next, the table is searched for a P lock for the named data resource in 105. Assuming that the page is not yet cached and that the cache manager has not yet forwarded a P lock request for the page, the negative exit is taken from 105, the RESP GLM field of the entry in the local lock table is marked and the local lock manager sends a request 107 to the global lock manager in the form of a message. The local lock manager waits at 108 until receiving a message 109 from the global lock manager granting the requested lock. When the grant is received, the local lock manager deletes the mark in the RESP GLM field of the lock entry, queues the requesting transaction to the H field of the entry and grants the L lock to the transaction at 110. Assume now that the request for an L lock has been received under the condition that only a P lock is found in the local lock managers's table for the named page. In this case, the positive exit is taken from the decision 105, upon which the local lock manager will determine the resultant mode of the P lock in the table and compare it against the mode of the requested L lock. If the requested mode has a greater magnitude than the resultant mode of the P lock, the negative exit is taken from the test 120, a new resultant mode equal to the requested mode is computed which would be requested from GLM. Then, a mark 122 is placed in the RESP GLM field for the requested L lock and the logic enters the sequence 107, 108, 109, 110 through logic point B. In this sequence, the global lock manager, upon receiving the LP lock request 107 will find an LP lock entry for the requesting DBMS which permitted the local lock manager to grant the P lock in the table. Now, the request to the global lock manager seeks to upgrade the magnitude of the mode of the previously-granted LP lock. In this case, if there are no other LP lock entries for the identified data resource, the existing LP lock for the requesting local lock manager will have its mode upgraded. This will be communicated by the global lock manager on a grant message 109. Upon receipt of the grant message, the local lock manager will remove the mark 122 from the RESP GLM field of the L lock entry and grant the L lock at 110. Assume now, when the request 100 is received, another L lock for the named data resource is found in the local lock manager's table. In this case, the positive exit is taken from the test 102 and the mode of the requested lock is tested against the mode of the granted lock at 130 to determine whether they are compatible. Assuming that the requested mode is incompatible with the previously-granted L lock, the local lock manager queues the requesting transaction in the R field of the L lock table entry and the transaction waits at 133 until the data resource is unlocked by the owning transaction. Upon unlocking at 134, the mode of the requested L lock is subjected to a test 135 of its magnitude relative to the resulting magnitude of any other locks on the named data resource remaining in the local lock manager's table. Assuming surrender of the L lock first encountered at 102, the unlock 134 will have placed a Null value in the Mode field of the L lock entry. On the other hand, if the previously-locking transaction has merely downgraded the mode of the existing L lock, the magnitude value will have been lowered. The test 135 will therefore compare the mode value of the requested lock against a resultant mode value calculated according to Table I. If the resultant mode value is greater than or equal to the requested value, the positive exit is taken from the test 135, the requested mode is placed in the Mode field of the L lock entry and lock is granted at 110. Returning once more to the test 130 and assuming that the mode for the requested L lock is compatible with the mode of the existing L lock on the identified data resource, the positive exit is taken from the test 130 and the RESP GLM field of the L lock entry is inspected at 136. If the field is unmarked, the mode of the requested lock is compared against the mode of the granted lock at 137 to determine whether the resultant mode must be upgraded to the greatest magnitude of the compatible modes of L and P locks. If not, the requesting transaction is queued to the H field of the L lock entry and the lock is granted. If upgrade is required, the positive exit from the test 137 carries the operation to entry point A in the local lock manager logic and results in a message exchange between the local lock manager and global lock manager to upgrade the mode of the LP lock via steps 106-109, following which the requestor is queued to the H field of the L lock entry and the lock is granted at 110. If the test 136 shows that a message from the global lock manager is expected in respect of the L lock entry, the positive exit is taken, the transaction is placed in wait state at 138 until a grant message is received from the global lock manager 139. Following this, the mark is removed from the RESP GLM field, the requesting transaction is queued to the H field and the lock is granted at 110. The operation of the invention in response to a P lock request is illustrated in FIG. 5; refer also to FIGS. 2 and 3 for an explanation of this operation. FIG. 5 illustrates logic inherent in the local lock managers 46, 47 for response to request for a P lock from a cache manager 38, 39. A request is received at 200. The local lock manager consults its local lock table to determine at 202 whether the P lock for the named data resource has been granted. Assume that the cache manager has not yet cached this page, in which case the negative exit will be taken from 202, a P lock entry will be made and entered into local lock manager's table at 208 and the table will then be scanned for an L lock entry for the named data resource. Assuming that no L lock has been requested for the named resource, the negative exit is taken from 210, the RESP GLM field of the P lock entry is marked in the local lock table at 211, an LP lock request is sent at 212, and a reply is awaited from the global lock manager at 213. Once the requested LP lock has been granted by a message 214, the RESP GLM field of the P lock entry is cleared and the P lock is granted at 215. Returning to test 210, assume that an L lock entry for the named data resource is found in the local lock table. The positive exit is taken and the resultant mode of the holder's entries is tested against the requested mode in 220. If the requested mode is not greater than the resultant mode, the positive exit is taken from the test 220, the requested mode value is placed in the Mode field of the requested P lock, and lock is granted at 215. Assuming that the requested mode for the P lock is greater than the resultant mode tested at 220; a new resultant mode is computed which includes the requested lock mode, the RESP GLM field of the P lock entry in the local lock table is marked at 224, and an updating of the LP lock mode is effected beginning at C in FIG. 5. When the updating of the LP lock is completed, the RESP GLM field of the P lock entry is cleared and the P lock is granted at 215. Returning to test 202, assume that the P lock request 200 is submitted by the cache manager in order to update the mode of an existing P lock. In this case, the positive exit is taken from test 202 and the logic is re-entered at A in FIG. 5. COHERENCY WITH LP LOCKING In the coherency protocol discussed above in respect of the no-force-at-commit policy using the P lock in a prior art hierarchical locking structure, a description was given of how P locks achieve coherency of a changed page in multiple buffers. Generally, inter-system coherency of a changed page is maintained in the same way via LP locks. However, a few differences do occur as a result of treating the L and P locks on a page as a single lock at the global lock manager. First, without LP locking, some prior art systems may require the global lock manager to detect lock conflict for L and P locks for any page when a corresponding incompatible lock request is made from another system. With LP locking, the global lock manager would detect a lock conflict on a page when an incompatible L or P lock request is made to the local lock manager of another system. The receiving local lock manager would forward an LP lock request having a mode conflicting with the existing LP lock maintained by the global lock manager for the same page for a different system. In this case, the inventors contemplate that the global lock manager would invoke a lock conflict protocol by, for example, sending a lock conflict message to the local lock manager owning the LP lock. In the case above where LP locking is not practiced and the global lock manager received L and P lock requests, a local lock manager would invoke its cache manager's lock conflict routine upon receiving a lock conflict message for a P lock request from the global lock manager. Because the L and P locks are maintained separately by the global lock manager in this case, the local lock manager would not have to be aware of the tie in with the L lock as explained below for LP locking. With LP locking according to the invention, an owning local lock manager upon receiving the lock conflict message from the global lock manager would invoke its cache manager's lock conflict routine after any L locks on the identified data resource become compatible with the mode of the requested LP lock. Assume, for example, that a transaction in system S1 holds an X-mode L lock to update page A and the cache manager in S1 holds an X-mode P lock because page A has changed. Assume further that a transaction in system S2 requests an L lock on page A, in which case the local lock manager for system S2 would send an LP lock request to the global lock manager. Upon receiving the request from system S2, the global lock manager would send a lock conflict message to system S1. Upon receiving the message, the local lock manager in system S1 would invoke its cache manager's lock conflict routine after the transaction in system S1 releases its L lock, that is, after the transaction commits. This ensures that the cache manager's lock conflict routine would transfer only that version of the page which has committed updates. Consider an example when a local lock manager would invoke its cache manager's lock conflict routine immediately. First, assume that in system S2 a transaction or the cache manager causes the local lock manager to generate an S-mode request for a LP lock on page A. Assume further that in system S1, page A is P-locked in X-mode and either not L-locked or L-locked in S-mode. In this case, the cache manager of system S1 has the updated version of page A cached, with the page either being read by a transaction or not used at all. The changes to the page are already committed, therefore the page can be transferred to another system without waiting for any transaction to commit. However, if the LP lock requested by system S2 is in X-mode, the local lock manager in system S1 would wait for the transaction holding the L lock on the page in S-mode to release the lock before invoking cache manager's conflict routine. The inventors have described a technique which saves messages for transaction locking and cache coherency when multiple instances of a database system (DBMS) share data by a shared data storage. In a multi-system environment, the locking function requires coordination among the multiple DBMS's, which is typically done via messages between systems. Messages have processing overhead and increase latency. This impacts transaction lock hold time and response time. Therefore, savings of lock and unlock calls is an important performance consideration. The technique of the invention, called LP locking, saves messages for locking when the unit of ownership of a data resource by a transaction is the same as the unit of caching that resource by the cache manager. The local lock manager hides the distinction between L and P locks for the same data resource from the global lock manager. The L and P locks for data resource, though distinct at the local lock manager, are known as a single LP lock at the global lock manager. The local lock manager can grant a lock locally based on the ownership of another related lock or suppress an unlock call since the information kept at the global lock manager does not change. While the invention has been described with respect to a preferred embodiment, it is to be understood by those skilled in the art that various changes in detail may be made to the invention without departing from the scope, spirit and teaching presented herein. Accordingly, the invention is to be limited only as specified in the following claims:
|
Same subclass Same class Consider this |
||||||||||