Transaction-based locking approach

Details Transaction-based locking approach Transaction-based locking approach

1999-04-16

2002-06-25

Wong, Peter (Department: 2181)

Electrical computers and digital data processing systems: input/

Access locking

C710S220000, C710S240000

Reexamination Certificate

active

06412034

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to information systems, and more specifically, to an approach for providing access to resources in information systems.
BACKGROUND OF THE INVENTION
In information systems, processes require access to resources to perform work. As used herein, the term “resource” refers to any object that can be accessed in an information system. In a hardware context, examples of resources include, but are not limited to, printers, disk drives and memory. In a software context, examples of resources include, but are not limited to, data items and routines. In information systems it is often desirable to allow only one process at a time to access a particular resource to maintain consistency. For example, if while a first process is updating a particular resource, a second process is allowed to read from the particular resource, then the second process may read an intermediate value of the particular resource that is different than the final value of the particular resource after the first process has completed its updates. As a result, the second process may erroneously believe that at the time the second process read from the particular resource, that the particular resource reflected all of the changes made by the first process. In this situation, an inconsistency has been introduced into the information system with respect to the value of the particular resource, thereby compromising the integrity of the data on the information system.
To address situations such as this, various mechanisms are used to ensure the integrity of resources that can be accessed by multiple processes. In particular, some information systems use locking mechanisms to manage and coordinate access to shared resources. In such systems, each process may be required to obtain a lock on a resource before accessing the resource. The type and parameters of the lock determine the scope of the access rights granted to the obtaining process. The appropriate grant of locks to resources ensures compatible access to the resources by concurrent processes. In the previous example, the first process would request and be granted a lock on the particular resource prior to updating the particular resource. While the first process holds the lock on the particular resource, the first process may make updates to the particular resource, but the second process may not access the particular resource. Once the first process has completed updating the particular resource, the lock is released. The second process can then access the particular resource and see all of the updates made to the particular resource by the first process.
Locks are typically allocated and managed by a process referred to as a lock manager. Lock managers are responsible for maintaining data that specifies the status of locks for a set of resources. Lock managers sometimes maintain a lock request queue for a set of resources to manage multiple lock requests. In distributed computing systems, resources, their assigned lock managers and processes obtaining locks on the resources may be located on separate nodes, or may be located on the same node. As used herein, the term “node” refers to any type of computing entity. Thus, a single computer may be a single node or support multiple nodes.
One of the problems with locking mechanisms is that there are situations in which it is desirable to simultaneously grant locks to multiple processes for a particular resource. It is helpful to consider this problem in the context of transaction processing in database systems. In the context of database systems, a “transaction” is a logical unit of work that is comprised of one or more database language statements.
Consider a situation where a first process P
1
processing a transaction T
1
obtains an exclusive lock LI on a resource R from a lock manager LM. A second process P
2
, that is also working on transaction T
1
, wishes to obtain a lock on resource R and submits a lock request to lock manager LM. Since lock L
1
on resource R is currently granted to process P
1
, lock manager LM places the lock request from the second process P
2
onto a lock request queue maintained by lock manager LM. When first process P
1
releases its lock L
1
on resource R, lock manager LM grants a lock L
2
on resource R to another process in the order in which lock requests were received. If the lock request by process P
2
is the first lock request for resource R in the lock request queue, then lock manager grants a lock to process P
2
. If however, a lock request for resource R by a third process P
3
was received prior to the request by the second process P
2
, then a lock on resource R will be granted to third process P
3
before the second process P
2
, irrespective of whether the third process P
3
is working on transaction T
1
. Thus, second process P
2
may or may not be the next process to be granted a lock on resource R, even though process P
2
is processing transaction T
1
. This characteristic of lock mechanisms is undesirable for several reasons.
Sometimes it is desirable to directly migrate a lock on resource R from the first process P
1
to the second process P
2
so that the second process P
2
can immediately continue processing of transaction T
1
without losing the changes made by process P
1
. If, as in the prior example, process P
3
is granted a lock on resource R before process P
2
, and process P
3
begins processing a transaction other than T
1
, then the changes made to resource R by process P
1
may be lost. Direct migration is often desirable for load balancing or efficiency purposes. For example, the first process P
1
may be experiencing an extremely high processing load that can be reduced by migrating the processing of transaction T
1
from the first process P
1
to the second process P
2
. Alternatively, the second process P
2
may be able to process transaction T
1
more efficiently than the first process P
1
.
Another situation where direct migration is desirable is when the first process P
1
fails, or the node on which first process P
1
resides fails, and it is possible for another process to complete processing of transaction T
1
. In this situation, sometimes referred to as “failover,” it is important to continue processing of transaction T
1
before a process working on another transaction makes a change to resource R. Otherwise, changes made to resource R up to the point of failure of the first process P
1
may be lost. With conventional locking mechanisms however, there is no way to guarantee that the process that is to continue processing of transaction T
1
will be the next process that is granted a lock on resource R when the first process P
1
releases its lock on resource R.
Suppose that the first process P
1
has failed before completing transaction T
1
and that the second process P
2
is to continue processing of transaction T
1
. At the time of failure of the first process P
1
, a lock request for a lock on resource R is sent by the second process P
2
to lock manager LM and placed on the lock request queue. When the lock held by the first process P
1
is released, the lock manager LM grants a lock on resource R to the process associated with the first lock request in the lock request queue. If the lock request associated with second process P
2
is first in the lock request queue, then the first transaction T
1
can be completed by the second process P
2
. If, however, a lock request associated with a third process P
3
is ahead of the lock request associated with the second process P
2
in the lock request queue, then the lock is granted to the third process P
3
before the second process P
2
. If the third process P
3
is working on a transaction other than transaction T
1
, then the third process P
3
may make updates to resource R, causing the changes made to resource R by the first process P
1
up to the point that the first process P
1
failed, to be lost. In this event, the changes made during the processing of the first transaction T
1
will have to be undone and the first transaction T

Affiliated with

Also associated with

Rating

Transaction-based locking approach does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Transaction-based locking approach, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transaction-based locking approach will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2977988