Resource locking approach

• US 6,539,446 B1
• Filed: 05/07/1999
• Issued: 03/25/2003
• Est. Priority Date: 05/07/1999
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle Corporation
• Inventors: Chan, Wilson Wai Shun
• Primary Examiner(s): THAI, XUAN MARIAN
• Application Number:
  US09/307,043
• Time in Patent Office: 1,418 Days
• Field of Search: 710/200, 711/147, 711/100, 714/1, 714/2, 714/6
• US Class Current: 710/200
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Abstract

A novel locking approach for managing access to resources generally includes generating and storing duplicate lock data that may be used if the original lock data upon which the duplicate lock data is based is lost or otherwise becomes unavailable. In response to granting a lock on a resource to a first process, lock data is generated that indicates that the lock on the resource was granted to the first process. Duplicate lock data is generated that indicates that the lock on the resource was granted to the first process. When a change is made to the lock data, the duplicate lock data is updated to reflect the change made to the lock data. If the lock data is lost or otherwise becomes unavailable, the duplicate lock data may be used to continue managing access to the resource.

Claims

1. A method for managing access to a particular resource, the method comprising the steps of:

receiving a request for a lock on the particular resource from a first process residing on a first node;

wherein the first process makes a change to the particular resource prior to knowing whether the duplicate lock data has been generated;

generating on a second node lock data that indicates that a lock on the particular resource has been granted to the first process;

generating duplicate lock data on a third node that indicates that the lock on the particular resource has been granted to the first process; and

providing an acknowledge message to the first process to indicate that the duplicate lock data has been generated and that a change made to the particular resource by the first process can be made permanent.

2. The method as recited in claim 1, further comprising the step of providing an acknowledge message to the first process to indicate that the lock on the particular resource has been granted to the first process.

3. The method as recited in claim 1, further comprising if the acknowledge message is not received by the first process after a specified period of time, then the first process undoing the change made to the particular resource.

4. The method as recited in claim 1, further comprising in response to a change made to the lock data, updating the duplicate lock data to reflect the change made to the lock data.

5. A method for managing access to a particular resource, the method comprising the steps of:

receiving a request for a lock on the particular resource from a first process residing on a first node;

generating on a second node lock data that indicates that a lock on the particular resource has been granted to the first process;

generating duplicate lock data on a third node that indicates that the lock on the particular resource has been granted to the first process; and

after a failure, using the duplicate lock data to manage access to the particular resource.

6. The method as recited in claim 5, further comprising generating new duplicate lock data on a fourth node that indicates the current lock status for the particular resource.

7. A method for managing access to a particular resource, the method comprising the steps of:

receiving a request for a lock on the particular resource from a first process residing on a first node;

generating on a second node lock data that indicates that a lock on the particular resource has been granted to the first process;

generating duplicate lock data on a third node that indicates that the lock on the particular resource has been granted to the first process; and

transferring responsibility for processing lock requests on the particular resource to a duplicate lock manager associated with the duplicate lock data.

8. A system comprising:

a resource; and

a locking mechanism for managing access to the resource, wherein the locking mechanism is configured to

generate, in response to a lock request from a first process, lock data that indicates that a lock has been granted on the resource to the first process,

generate duplicate lock data that indicates that the lock has been granted on the resource to the first process, and

provide an acknowledge to the first process to indicate that the duplicate lock data has been generated and that a change made to the resource by the first process can be made permanent.

9. A computer-readable medium carrying one or more sequences of one or more instructions for managing access to a particular resource, the one or more sequences of one or more instructions including instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of:

receiving a request for a lock on the particular resource from a first process residing on a first node;

wherein the first process makes a change to the particular resource prior to knowing whether the duplicate lock data has been generated;

generating on a second node lock data that indicates that a lock on the particular resource has been granted to the first process;

generating duplicate lock data on a third node that indicates that the lock on the particular resource has been granted to the first process; and

providing an acknowledge message to the first process to indicate that the duplicate lock data has been generated and that a change made to the particular resource by the first process can be made permanent.

10. The computer-readable medium as recited in claim 9, further comprising the step of providing an acknowledge message to the first process to indicate that the lock on the particular resource has been granted to the first process.

11. The computer-readable medium as recited in claim 9, further comprising if the acknowledge message is not received by the first process after a specified period of time, then the first process undoing the change made to the particular resource.

12. The computer-readable medium as recited in claim 9, further comprising in response to a change made to the lock data, updating the duplicate lock data to reflect the change made to the lock data.

13. A computer-readable medium carrying one or more sequences of one or more instructions for managing access to a particular resource, the one or more sequences of one or more instructions including instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of:

receiving a request for a lock on the particular resource from a first process residing on a first node;

generating on a second node lock data that indicates that a lock on the particular resource has been granted to the first process;

generating duplicate lock data on a third node that indicates that the lock on the particular resource has been granted to the first process; and

after a failure, using the duplicate lock data to manage access to the particular resource.

14. The computer-readable medium as recited in claim 13, further comprising generating new duplicate lock data on a fourth node that indicates the current lock status for the particular resource.

15. A computer-readable medium carrying one or more sequences of one or more instructions for managing access to a particular resource, the one or more sequences of one or more instructions including instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of:

receiving a request for a lock on the particular resource from a first process residing on a first node;

generating on a second node lock data that indicates that a lock on the particular resource has been granted to the first process;

generating duplicate lock data on a third node that indicates that the lock on the particular resource has been granted to the first process; and

transferring responsibility for processing lock requests on the particular resource to a duplicate lock manager associated with the duplicate lock data.