Method, system, and program for managing locks enabling access to a shared resource

• US 20040068563A1
• Filed: 10/08/2002
• Published: 04/08/2004
• Est. Priority Date: 10/08/2002
• Status: Active Grant

• Current Assignee: International Business Corporation (Kleangas Energy Technologies, Inc.)
• Original Assignee: International Business Machines Corporation
• Inventors: Ahuja, Chetan, Palmer, John Davis, Filz, Frank Stewart
• Granted Patent: US 8,495,131 B2
• Time in Patent Office: Days
• US Class Current: 709/225
• CPC Class Codes: G06F 11/1402 Saving, restoring, recovering or retrying
• CPC Class Codes: G06F 11/2023 Failover techniques
• CPC Class Codes: G06F 11/2028 eliminating a faulty processor or activating a spare
• CPC Class Codes: G06F 11/2041 with more than one idle spare processing component
• CPC Class Codes: G06F 11/2046 where the redundant components share persistent storage G06F11/2043 takes precedence
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1097 for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

Provided are a method, system, and program for managing locks enabling access to a shared resource. A first server receives a lock request from a client for the shared resource. A determination is made as to whether a second server owns the client locks. The first server issues a request to the second server to transfer ownership of the client locks to the first server, wherein the client lock requests are handled by the server owning the client locks.

Claims

1. An article of manufacture for managing locks enabling access to a shared resource in a network environment including a first server and second server, wherein the article of manufacture causes operations to be performed at the first server, comprising:

receiving a lock request from a client for the shared resource;

determining whether the second server owns the client locks; and

issuing a request to the second server to transfer ownership of the client locks to the first server, wherein the client lock requests are handled by the server owning the client locks.

2. The article of manufacture of claim 1, wherein the article of manufacture further causes the first server to perform:

if the first server owns the locks for the client, then processing the client lock request.

3. The article of manufacture of claim 1, wherein the article of manufacture further causes the first server to perform:

providing client lock information accessible to both the first and second servers indicating the server owning the locks for the client, wherein the second server as indicated in the client lock information as owning the locks for the client.

4. The article of manufacture of claim 1, wherein the article of manufacture further causes the first server to perform:

maintaining client lock state information indicating a state of the server with respect to the client locks, wherein only one server has client lock state information.

5. The article of manufacture of claim 4, wherein there are a plurality of clients capable of sending lock requests to the servers to access the shared resource, and wherein the first server maintains client lock state information for each client.

6. The article of manufacture of claim 1, wherein the server client lock state information indicates whether the first server or another server owns the locks for the client.

7. The article of manufacture of claim 4, wherein the second server sets the client lock state information to indicate that the second server is giving up the client locks after receiving the request from the first server for the locks.

8. The article of manufacture of claim 7, wherein the article of manufacture further causes the first server to perform:

receiving a message from the second server to take the client locks after setting the client lock state information to indicate that the second server is transferring the client locks.

9. The article of manufacture of claim 1, wherein the article of manufacture further causes the first server to perform:

issuing a request for the client locks, including exclusive client locks, before the second server has released exclusive client locks, wherein both the first server and second server simultaneously have exclusive client locks during the transfer of ownership of the client locks from the second server to the first server.

10. The article of manufacture of claim 9, wherein the article of manufacture further causes the first server to perform:

sending a message to the second server after obtaining the client locks, including any exclusive locks, to release the client locks, wherein the second server releases the client locks in response to receiving the message from the first server to release the client locks.

11. The method of claim 10, wherein the article of manufacture further causes the first server to perform:

maintaining client lock state information indicating a state of the server with respect to the client locks, wherein only one server has client lock state information, wherein the second server sends a message that the client locks have been released after the client locks owned by the second server have been released; and

setting the client lock state information to indicate that the first server has the client locks after receiving the message from the second server that the client locks have been released.

12. The article of manufacture of claim 1, wherein the article of manufacture further causes the first server to perform:

receiving the lock request after a load balancing operation directs client lock requests for the shared resource from the second server to the first server.

13. The method of claim 1, wherein the shared resource comprises a common storage space.

14. A server for managing locks enabling access to a shared resource in a network environment including a plurality of remote servers and clients, comprising:

a port adapted to receive communication from the remote servers and at least one client;

code implemented in the server to cause the server to perform;

(i) receiving a lock request from a client for the shared resource through the port;

(ii) determining whether one remote server owns the client locks; and

(iii) issuing a request to the remote server to transfer ownership of the client locks, wherein the client lock requests are handled by the server owning the client locks.

15. The system of claim 14, wherein the code further causes the server to perform:

if the first server owns the locks for the client, then processing the client lock request.

16. The system of claim 14, wherein the code further causes the server to perform:

providing client lock information accessible to both the first and second servers indicating the server owning the locks for the client, wherein the second server as indicated in the client lock information as owning the locks for the client.

17. The system of claim 14, wherein the code further causes the server to perform:

maintaining client lock state information indicating a state of the server with respect to the client locks, wherein only one server has client lock state information indicating that the server has the client locks.

18. The system of claim 14, wherein the remote server sets the client lock state information to indicate that the remote server is giving up the client locks after receiving the request from the server for the locks.

19. The system of claim 18, wherein the code further causes the server to perform:

receiving a message from the remote server to take the client locks after setting the client lock state information to indicate that the remote server is transferring the client locks.

20. The system of claim 14, wherein the code further causes the server to perform:

issuing a request for the client locks, including exclusive client locks, before the remote server has released exclusive client locks, wherein both the server and remote server simultaneously have exclusive client locks during the transfer of ownership of the client locks from the remote server to the server.

21. The system of claim 20, wherein the code further causes the server to perform:

sending a message to the remote server after obtaining the client locks, including any exclusive locks, to release the client locks, wherein the remote server releases the client locks in response to receiving the message from the server to release the client locks.

22. The system of claim 21, wherein the code further causes the server to perform:

maintaining client lock state information indicating a state of the server with respect to the client locks, wherein only one server has client lock state information, wherein the remote server sends a message that the client locks have been released after the client locks owned by the remote server have been released; and

setting the client lock state information to indicate that the server has the client locks after receiving the message from the remote server that the client locks have been released.

23. A server for managing locks enabling access to a shared resource in a network environment including a plurality of remote servers and clients, comprising:

means for receiving communication from the remote servers and at least one client;

means for receiving a lock request from a client for the shared resource through the port;

means for determining whether one remote server owns the client locks; and

means for issuing a request to the remote server to transfer ownership of the client locks, wherein the client lock requests are handled by the server owning the client locks.

24. A method for managing locks enabling access to a shared resource, comprising:

receiving, at a first server, a lock request from a client for the shared resource;

determining whether a second server owns the client locks; and

issuing, with the first server, a request to the second server to transfer ownership of the client locks to the first server, wherein the client lock requests are handled by the server owning the client locks.

25. The method of claim 24, further comprising:

if the first server owns the locks for the client, then processing, with the first server, the client lock request.

26. The method of claim 24, further comprising:

providing client lock information accessible to both the first and second servers indicating the server owning the locks for the client, wherein the first server issues the request to the first server indicated in the client lock information as owning the locks for the client.

27. The method of claim 26, wherein the first and second servers have network addresses including a shared virtual interface address portion, and wherein the client lock information indicates the shared virtual interface address portion of the server owning the locks for the client.

28. The method of claim 24, further comprising:

maintaining, by the first and second servers, client lock state information indicating a state of the server with respect to the client locks, wherein only one server has client lock state information indicating that the server has the client locks.

29. The method of claim 28, wherein there are a plurality of clients capable of sending lock requests to the servers to access the shared resource, and wherein the servers maintain client lock state information for each client capable of sending lock requests.

30. The method of claim 28, wherein the first server client lock state information indicates whether the first server or another server owns the locks for the client.

31. The method of claim 24, further comprising:

setting, by the second server, the client lock state information to indicate that the second server is giving up the client locks after receiving the request from the first server for the locks.

32. The method of claim 31, further comprising:

sending, by the second server, a message to the first server to take the client locks after setting the client lock state information to indicate that the second server is transferring the client locks.

33. The method of claim 24, further comprising:

issuing, by the first server, a request for the client locks, including exclusive client locks, before the second server has released exclusive client locks, wherein both the first server and second server simultaneously have exclusive client locks during the transfer of ownership of the client locks from the second server to the first server.

34. The method of claim 33, further comprising:

sending, by the first server, a message to the second server after obtaining the client locks, including any exclusive locks, to release the client locks; and

releasing, by the second server, the client locks in response to receiving the message from the first server to release the client locks.

35. The method of claim 34, further comprising:

maintaining, by the first and second servers, client lock state information indicating a state of the server with respect to the client locks, wherein only one server has client lock state information indicating that the server has the client locks;

sending, by the second server, a message that the client locks have been released after the client locks owned by the second server have been released; and

setting, by the first server, the client lock state information to indicate that the first server has the client locks after receiving the message from the second server that the client locks have been released.