Electrical computers and digital data processing systems: input/ – Access locking
Reexamination Certificate
2002-06-10
2003-12-23
Ray, Gopal C. (Department: 2181)
Electrical computers and digital data processing systems: input/
Access locking
C707S793000, C709S229000
Reexamination Certificate
active
06668295
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to the efficiency of data accessing techniques, and more specifically, to Distributed Lock Manager (DLM) lock conversions.
BACKGROUND OF THE INVENTION
In order to promote efficiency, computer networks have been developed in which processes running on many computer devices or “nodes” can share resources. For example, instead of having to purchase one printer for every computer, users may purchase a single printer that may be connected to a network that has many computers. Processes on each computer on the network access the printer only when the processes require the printer.
Moreover, in some circumstances, certain types of resources, such as data blocks of a storage medium or tables stored on a storage medium must necessarily be shared so that all the users on the network get the same information. For example, consider a hypothetical company, Acme, which needs to track its inventory. A database containing Acme's inventory information and which is constantly updated by various users in the company is useful only if all users of the database have access to the same information at any given time. On the other hand, if Acme maintained several independent databases on the same set of inventory, with some users updating some of the information on one database and some other users updating information on a different database, then none of these databases, by themselves, would correctly reflect the inventory in Acme. Thus, maintaining a multiplicity of independent inventory databases in Acme would be meaningless because the goal is to enable the users to share with each other the most up-to-date and accurate information on Acme's inventory in the most efficient manner.
However, the sharing of resources cannot be done in a haphazard fashion but rather in a managed and orderly fashion. For example, a resource such as a table stored on a storage medium, may be concurrently accessed in some ways (e.g. read) by multiple processes, but accessed in other ways (e.g. written to) by only one process at a time. Consequently, mechanisms have been developed which control access to resources.
One such mechanism is referred to as a lock. A lock is a data structure that indicates that a particular process has been granted certain rights with respect to the resource. There are many types of locks. Some types of locks may be shared by many processes, while other types of locks prevent any other locks to be granted on the same resource.
Due to the various permissions and guarantees associated with these locks, certain lock combinations are not allowed. For example ownership of an exclusive lock grants a process permission to do anything with a resource, and guarantees that no other process is performing any operation on the resource. Thus if a process owns an exclusive mode lock on a resource, then no other process can be granted any lock other than a NULL mode lock, which grants a process no permission to access the resource in any manner. Thus, the ownership of locks has to be managed in a manner to provide for efficient accessing of resources.
One management approach is to use a lock manager, an entity that is responsible for granting, queuing, and keeping track of locks on one or more resources. Before a process can perform an operation on a resource, the process is required to obtain a lock that grants to the process the right to perform the desired operation on the resource. To obtain a lock, a process transmits a request for the lock to a lock manager. To manage the use of resources in a network system, lock managers are executed on one or more nodes in the network. Associated with the use of lock managers is an overhead in the form of messages being passed back and forth between the nodes of the computer network. For example, in order to obtain a lock, a process residing on one node may have to send a message to a lock manager residing on a different node.
According to one implementation, a lock manager implements two types of objects: a resource object and a lock. Resource objects are data structures that correspond to actual resources. An application that uses a lock manager establishes a mapping between actual resources and resource objects. Each resource object has two queues: a granted queue and a convert queue. The granted queue is an unordered list of locks that have been granted. The convert queue is a partially ordered list of locks that have been requested, but not yet granted. Typically, a request for a lock is actually a convert request, where a process holding a lock is requesting that the lock it holds be converted from one mode of lock to a different mode of lock.
Locks are data structures that identify a process and a lock mode. Lock managers attach locks to the granted queues of resource objects to indicate that the process identified in the lock has been granted a lock of the type indicated in the lock on the resource that corresponds to the resource object to which the lock is attached.
FIG. 1
is a block diagram illustrating a typical lock manager
106
. Lock manager
106
is a process that is configured to manage a resource object
100
stored in a memory
108
. The resource object includes a granted queue
102
and a convert queue
104
. Lock manager
106
has attached three locks
110
,
112
and
114
to the granted queue
102
, and one convert request
130
to the convert queue
104
.
All locks and convert requests have a process ID portion and a lock mode portion. The process ID portion
16
of lock
110
indicates that a process PROC_
1
owns lock
110
, and the lock mode portion
118
of lock
110
indicates that lock
110
is an exclusive lock. The process ID portion
120
of lock
112
indicates that lock
112
is owned by a process PROC_
2
, and the lock mode portion
122
of lock
112
indicates that lock
112
is a NULL mode lock. The process ID portion
124
of lock
114
indicates that lock
114
is owned by a process PROC_
3
, and the lock mode portion
126
of lock
114
indicates that lock
114
is a NULL lock. The process ID portion
132
of convert request
130
indicates that convert request
130
is associated with process PROC_
4
, and the lock mode portion
136
of convert request
130
indicates that PROC_
4
currently holds a NULL mode lock on the resource. In addition to a lock mode portion
136
, convert request
130
has a requested mode portion
134
that indicates that PROC_
4
is requesting an exclusive mode lock.
Lock manager
106
has attached locks
110
,
112
and
114
to granted queue
102
, indicating that PROC_
1
currently has exclusive ownership of the resource that corresponds to resource object
100
. Lock manager
106
has attached convert request
130
to the convert queue
104
, indicating that PROC_
4
has requested but has not yet been granted an exclusive mode lock on the resource associated with resource object
100
.
Information pertaining to any given resource may be stored in the resource object that corresponds to the resource. Each resource object is stored in the memory of a single node. The node on which a resource object is stored is referred to as the master node for the resource object.
According to one lock management approach, a process initially establishes a NULL mode lock on all resources that the process will possibly use. Then, when the process actually requires access to a resource, the process requests that its NULL mode lock be converted to a lock that grants to the process the rights to perform the desired operation.
For example, to delete a resource such as a table stored on a storage medium, a process must obtain an exclusive mode lock on the resource object that corresponds to the table. To obtain the exclusive mode lock, the process transmits a message to the lock manager that controls the resource object that corresponds to the table. In the message, the process requests that its current NULL mode lock be converted to an exclusive mode lock. If no other process has requested a conversion, and if no currently granted locks would prevent
Becker Edward A.
Hickman Palermo & Truong & Becker LLP
Oracle International Corporation
Ray Gopal C.
LandOfFree
Anticipatory lock mode conversions in a lock management system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Anticipatory lock mode conversions in a lock management system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Anticipatory lock mode conversions in a lock management system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3156546