METHOD, SYSTEM, AND PROGRAM FOR LOCK AND TRANSACTION MANAGEMENT

• US 20070282839A1
• Filed: 07/13/2007
• Published: 12/06/2007
• Est. Priority Date: 05/01/2003
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Walker, Michael
• Granted Patent: US 7,870,111 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• CPC Class Codes: Y10S 707/99938 Concurrency, e.g. lock management in shared database
• CPC Class Codes: Y10S 707/99944 Object-oriented database structure
• CPC Class Codes: Y10S 707/99952 Coherency, e.g. same view to multiple users

Abstract

Disclosed is a method, system, and program for locking management. A command is received that specifies an operation identifier. It is determined whether the command is associated with a transaction using the operation identifier. If it is determined that the command is associated with a transaction, operating at a transaction level of locking. Further disclosed is a method, system, and program for lock management. Under control of a lock manager, lock request queuing is performed, heartbeat functions are performed, and state information is maintained.

Claims

1. A method for locking management comprising:

under control of a lock manager that provides locking functions for locking aware clients and locking aware agents,

receiving a command that specifies an operation identifier, wherein the operation identifier is a compound key with a first part indicating whether the operation identifier was generated by a transaction manager, with a second part being one of a lock management group name and a transaction manager name, and with a third part being a unique number in a context of one of the lock management group and the transaction manager;

determining whether the command is associated with a transaction using the operation identifier by determining whether the operation identifier was generated by a transaction manager using the first part of the operation identifier; and

if it is determined that the command is associated with a transaction, operating at a transaction level of locking that uses the transaction manager.

2. The method of claim 1, wherein if it is determined that the command is associated with a transaction, further comprising:

supporting atomicity, isolation, consistency, and durability of the transaction.

3. The method of claim 1, wherein if it is determined that the command is not associated with a transaction, further comprising:

operating at an isolation level of locking until it is determined that a lock is released.

4. The method of claim 3, further comprising:

using a lock to block actions from modifying information used by the command.

5. The method of claim 4, wherein the lock is a read lock.

6. The method of claim 1, further comprising:

in response to determining that the lock is released, operating at a client controlled level of locking.

7. The method of claim 6, wherein atomicity, isolation, consistency, and durability of transactions are not supported.

8. A system for lock management, comprising:

a lock manager that provides locking functions for locking aware clients and locking aware agents including;

a processor;

a computer readable medium accessible to the processor; and

program logic including code capable of causing the processor to perform;

receiving a command that specifies an operation identifier, wherein the operation identifier is a compound key with a first part indicating whether the operation identifier was generated by a transaction manager, with a second part being one of a lock management group name and a transaction manager name, and with a third part being a unique number in a context of one of the lock management group and the transaction manager;

determining whether the command is associated with a transaction using the operation identifier by determining whether the operation identifier was generated by a transaction manager using the first part of the operation identifier; and

if it is determined that the command is associated with a transaction, operating at a transaction level of locking that uses the transaction manager.

9. The system of claim 8, wherein if it is determined that the command is associated with a transaction, the code is capable of causing the processor to further perform:

supporting atomicity, isolation, consistency, and durability of the transaction.

10. The system of claim 8, wherein if it is determined that the command is not associated with a transaction, the code is capable of causing the processor to further perform:

operating at an isolation level of locking until it is determined that a lock is released.

11. The system of claim 10, wherein the code is capable of causing the processor to further perform:

using a lock to block actions from modifying information used by the command.

12. The system of claim 11, wherein the lock is a read lock.

13. The system of claim 8, wherein the code is capable of causing the processor to further perform:

in response to determining that the lock is released, operating at a client controlled level of locking.

14. The system of claim 13, wherein atomicity, isolation, consistency, and durability of transactions are not supported.

15. An article of manufacture including program logic for lock management, wherein the program logic causes operations to be performed, the operations comprising:

under control of a lock manager that provides locking functions for locking aware clients and locking aware agents,

receiving a command that specifies an operation identifier, wherein the operation identifier is a compound key with a first part indicating whether the operation identifier was generated by a transaction manager, with a second part being one of a lock management group name and a transaction manager name, and with a third part being a unique number in a context of one of the lock management group and the transaction manager;

determining whether the command is associated with a transaction using the operation identifier by determining whether the operation identifier was generated by a transaction manager using the first part of the operation identifier; and

if it is determined that the command is associated with a transaction, operating at a transaction level of locking that uses the transaction manager.

16. The article of manufacture of claim 15, wherein if it is determined that the command is associated with a transaction, the operations further comprise:

supporting atomicity, isolation, consistency, and durability of the transaction.

17. The article of manufacture of claim 15, wherein if it is determined that the command is not associated with a transaction, the operations further comprise:

operating at an isolation level of locking until it is determined that a lock is released.

18. The article of manufacture of claim 17, the operations further comprising:

using a lock to block actions from modifying information used by the command.

19. The article of manufacture of claim 18, wherein the lock is a read lock.

20. The article of manufacture of claim 15, the operations further comprising:

in response to determining that the lock is released, operating at a client controlled level of locking.

21. The article of manufacture of claim 20, wherein atomicity, isolation, consistency, and durability of transactions are not supported.

22. A system for lock management, comprising:

under control of a lock manager that provides locking functions for locking aware clients and locking aware agents,

means for receiving a command that specifies an operation identifier, wherein the operation identifier is a compound key with a first part indicating whether the operation identifier was generated by a transaction manager, with a second part being one of a lock management group name and a transaction manager name, and with a third part being a unique number in a context of one of the lock management group and the transaction manager;

means for determining whether the command is associated with a transaction using the operation identifier by determining whether the operation identifier was generated by a transaction manager using the first part of the operation identifier; and

means for, if it is determined that the command is associated with a transaction, operating at a transaction level of locking that uses the transaction manager.

23. A method for lock management, comprising:

under control of a lock manager that manages lock requests received from one or more multi-vendor clients and directed to one or more multi-vendor agents and manages responses from the one or more multi-vendor agents to the one or more multi-vendor clients,

performing lock request queuing for lock requests that are refused the one or more multi-vendor agents;

performing functions to ensure that the one or more multi-vendor clients and the one or more multi-vendor agents are functioning properly by sending a signal to one of the one or more multi-vendor clients and the one or more multi-vendor agents and receiving a response to the signal that indicates proper functioning; and

maintaining state information, wherein the state information includes locks held by the one or more multi-vendor clients and identifies the one or more multi-vendor agents holding locks.

24. The method of claim 23, wherein the state information reflects states of the one or more multi-vendor clients and the one or more multi-vendor agents.

25. The method of claim 24, wherein one of the multi-vendor clients is locking aware.

26. The method of claim 24, wherein one of the multi-vendor clients is locking unaware.

27. The method of claim 23, further comprising:

enforcing a locking protocol that defines interactions between the lock manager, the multi-vendor clients, and the multi-vendor agents.

28. The method of claim 23, further comprising:

receiving a read protected action on a resource;

holding a read lock on the resource; and

blocking write actions from writing to the resource.

29. The method of claim 23, further comprising:

receiving a write protected action on a resource;

holding a change lock on the resource;

blocking write actions from writing to the resource; and

blocking read and change locks on the resource.

30. A system for lock management, comprising:

a lock manager that manages lock requests received from one or more multi-vendor clients and directed to one or more multi-vendor agents and manages responses from the one or more multi-vendor agents to the one or more multi-vendor clients,

a processor;

a computer readable medium accessible to the processor; and

program logic including code capable of causing the processor to perform;

performing lock request queuing for lock requests that are refused the one or more multi-vendor agents;

performing heartbeat functions to ensure that the one or more multi-vendor clients and the one or more multi-vendor agents are functioning properly by sending a signal to one of the one or more multi-vendor clients and the one or more multi-vendor agents and receiving a response to the signal that indicates proper functioning; and

maintaining state information, wherein the state information includes locks held by the one or more multi-vendor clients and identifies the one or more multi-vendor agents holding locks.

31. The system of claim 30, wherein the state information reflects states of the one or more multi-vendor clients and the one or more multi-vendor agents.

32. The system of claim 31, wherein one of the multi-vendor clients is locking aware.

33. The system of claim 31, wherein one of the multi-vendor clients is locking unaware.

34. The system of claim 30, wherein the code is capable of causing the processor to further perform:

enforcing a locking protocol that defines interactions between the lock manager, the multi-vendor clients, and the multi-vendor agents.

35. The system of claim 30, wherein the code is capable of causing the processor to further perform:

receiving a read protected action on a resource;

holding a read lock on the resource; and

blocking write actions from writing to the resource.

36. The system of claim 30, wherein the code is capable of causing the processor to further perform:

for receiving a write protected action on a resource;

for holding a change lock on the resource;

for blocking write actions from writing to the resource; and

for blocking read and change locks on the resource.

37. An article of manufacture including program logic for lock management, wherein the program logic causes operations to be performed, the operations comprising:

under control of a lock manager that manages lock requests received from one or more multi-vendor clients and directed to one or more multi-vendor agents and manages responses from the one or more multi-vendor agents to the one or more multi-vendor clients,

performing lock request queuing for lock requests that are refused the one or more multi-vendor agents;

performing heartbeat functions to ensure that the one or more multi-vendor clients and the one or more multi-vendor agents are functioning properly by sending a signal to one of the one or more multi-vendor clients and the one or more multi-vendor agents and receiving a response to the signal that indicates proper functioning; and

maintaining state information, wherein the state information includes locks held by the one or more multi-vendor clients and identifies the one or more multi-vendor agents holding locks.

38. The article of manufacture of claim 37, wherein the state information reflects states of the one or more multi-vendor clients and the one or more multi-vendor agents.

39. The article of manufacture of claim 38, wherein one of the multi-vendor clients is locking aware.

40. The article of manufacture of claim 38, wherein one of the multi-vendor clients is locking unaware.

41. The article of manufacture of claim 37, the operations further comprising:

enforcing a locking protocol that defines interactions between the lock manager, the multi-vendor clients, and the multi-vendor agents.

42. The article of manufacture of claim 37, the operations further comprising:

receiving a read protected action on a resource;

holding a read lock on the resource; and

blocking write actions from writing to the resource.

43. The article of manufacture of claim 37, the operations further comprising:

receiving a write protected action on a resource;

holding a change lock on the resource;

blocking write actions from writing to the resource; and

blocking read and change locks on the resource.

44. A system for lock management, comprising:

under control of a lock manager that manages lock requests received from one or more multi-vendor clients and directed to one or more multi-vendor agents and manages responses from the one or more multi-vendor agents to the one or more multi-vendor clients,

means for performing lock request queuing for lock requests that are refused the one or more multi-vendor agents;

means for performing functions to ensure that the one or more multi-vendor clients and the one or more multi-vendor agents are functioning properly by sending a signal to one of the one or more multi-vendor clients and the one or more multi-vendor agents and receiving a response to the signal that indicates proper functioning; and

means for maintaining state information, wherein the state information includes locks held by the one or more multi-vendor clients and identifies the one or more multi-vendor agents holding locks.