Semantic response to lock requests to reduce coherence overhead in multi-node systems

• US 8,086,579 B1
• Filed: 01/22/2002
• Issued: 12/27/2011
• Est. Priority Date: 01/22/2002
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Chandrasekaran, Sashikanth, Bamford, Roger J.
• Primary Examiner(s): Chen, Susan Y
• Application Number:
  US10/056,716
• Time in Patent Office: 3,626 Days
• Field of Search: 707/8, 707/203, 707/1, 707/202, 718/104, 710/200, 716/146, 701/221
• US Class Current: 707/704
• CPC Class Codes: G06F 16/2343 Locking methods, e.g. distributed locking or locking implementation details

Abstract

Techniques are provided for lock management. The techniques are based on an enhanced lock management system that generates a semantic response in response to lock requests for a resource. The semantic response communicates both the underlying cause blocking the request, and information that may be used by the requester to obtain notification of when the underlying cause should no longer lead to denial of the lock request. The semantic response may be generated by the master of the resource, who provides the semantic response to the local lock manager of the lock requester. The semantic response may be retained by the local lock manager so that the semantic response can be provided to subsequent lock requesters, without need for interacting with another lock manager on another node.

Claims

1. A method, the method comprising the steps of:

a requester transmitting to a lock management system a request for a certain lock on a first resource;

said lock management system denying said request based on a blocking condition that, while in effect, said lock management system does not grant a request for a lock on a second resource different than said first resource;

said requester receiving from said lock management system a response that (1) denies said request for a certain lock on a first resource and (2) includes data that identifies the second resource; and

said requester determining said blocking condition is no longer in effect by performing certain steps that include;

said requester transmitting to said lock management system a request for a lock on said second resource; and

said requester receiving from said lock management system a response that grants said request for said lock on said second resource.

2. The method of claim 1, wherein said second resource is a transaction and said first resource is a resource locked for said transaction.

3. The method of claim 2, wherein said data that identifies a second resource includes a transaction id identifying said transaction.

4. The method of claim 1, wherein:

said first resource is a data block; and

said blocking condition is based on said data block undergoing a block-split operation.

5. The method of claim 4, wherein said data block is marked to indicate the data block is undergoing said block split operation.

6. The method of claim 1, further including in response to determining when said blocking condition no longer prevents said lock management system from granting a lock on said first resource, said requester informing said lock management system that said blocking condition is no longer in effect.

7. The method of claim 1, further including said requester informing said lock management system that said blocking condition is no longer effect by making another request for a lock of said first resource, said request including data specifying that said blocking condition is no longer effect.

8. A non-transitory computer-readable medium storing one or more sequences of instructions, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of:

a requester transmitting to a lock management system a request for a certain lock on a first resource;

said lock management system denying said request based on a blocking condition that, while in effect, said lock management system does not grant a request for a lock on a second resource different than said first resource;

said requester receiving from said lock management system a response that (1) denies said request for a certain lock on a first resource and (2) includes data that identifies the second resource; and

said requester determining said blocking condition is no longer in effect by performing certain steps that include;

said requester transmitting to said lock management system a request for a lock on said second resource; and

said requester receiving from said lock management system a response that grants said request for said lock on said second resource.

9. The computer-readable medium of claim 8, wherein said second resource is a transaction and said first resource is a resource locked for said transaction.

10. The computer-readable medium of claim 9, wherein said data that identifies a second resource includes a transaction id identifying said transaction.

11. The computer-readable medium of claim 8, wherein:

said first resource is a data block; and

said blocking condition is based on said data block undergoing a block-split operation.

12. The computer-readable medium of claim 11, wherein said data block is marked to indicate the data block is undergoing said block split operation.

13. The computer-readable medium of claim 8, the steps further including in response to determining when said blocking condition no longer prevents said lock management system from granting a lock on said first resource, said requester informing said lock management system that said blocking condition is no longer in effect.

14. The computer-readable medium of claim 8, the steps further including said requester informing said lock management system that said blocking condition is no longer effect by making another request for a lock of said first resource, said request including data specifying that said blocking condition is no longer effect.