Using secondary resource masters in conjunction with a...

Details Using secondary resource masters in conjunction with a... Using secondary resource masters in conjunction with a...

2000-10-24

2004-02-24

Thai, Xuan M. (Department: 2181)

Electrical computers and digital data processing systems: input/

Access locking

C709S241000, C714S002000

Reexamination Certificate

active

06697901

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates generally to managing resources that are accessible to a plurality of entities and, more specifically, to distributing the job of mastery of a resource by one primary resource master to one or more secondary resource masters.
BACKGROUND OF THE INVENTION
Database servers use resources while executing transactions. Even though resources may be shared between database servers, many resources may not be accessed in certain ways by more than one process at any given time. For example, resources such as data blocks of a storage medium or tables 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 a resource. There are many types of locks. Some types of locks may be shared on the same resource by many processes, while other types of locks prevent any other locks from being granted on the same resource.
The entity responsible for granting locks on resources is referred to as a lock manager. In a single node database system, a lock manager will typically consist of one or more processes on the node. In a multiple-node system, such as a multi-processing machine or a local area network, a lock manager may include processes distributed over numerous nodes. A lock manager that includes components that reside on two or more nodes is referred to as a distributed lock manager.
FIG. 1
is a block diagram of a multiple-node computer system
100
. Each node is executing an instance of a database server and a portion of a distributed lock management system
132
. Specifically, the illustrated system includes three nodes
102
,
112
and
122
on which reside database servers
104
,
114
and
124
, respectively, and lock manager units
106
,
116
and
126
, respectively. Database servers
104
,
114
and
124
have access to the same database
120
. The database
120
resides on a disk
118
that contains multiple blocks of data. Disk
118
generally represents one or more persistent storage devices that may be on any number of machines, including but not limited to the machines that contain nodes
102
,
112
and
122
.
A communication mechanism allows processes on nodes
102
,
112
, and
122
to communicate with each other and with the disks that contain portions of database
120
. The specific communication mechanism between the nodes and disk
118
will vary based on the nature of system
100
. For example, if the nodes
102
,
112
and
122
correspond to workstations on a network, the communication mechanism will be different than if the nodes
102
,
112
and
122
correspond to clusters of processors and memory within a multi-processing machine.
Before any of database servers
104
,
114
and
124
can access a resource shared with the other database servers, it must obtain the appropriate lock on the resource from the distributed lock management system
132
. Such a resource may be, for example, one or more blocks of disk
118
on which data from database
120
is stored.
Lock management system
132
stores data structures that indicate the locks held by database servers
104
,
114
and
124
on the resources shared by the database servers. If one database server requests a lock on a resource while another database server has a lock on the resource, the distributed lock management system
132
must determine whether the requested lock is consistent with the granted lock. If the requested lock is not consistent with the granted lock, then the requester must wait until the database server holding the granted lock releases the granted lock.
According to one approach, lock management system
132
maintains one master resource object for every resource managed by lock management system
132
, and includes one lock manager unit for each node that contains a database server. The master resource object for a particular resource stores, among other things, an indication of all locks that have been granted on or requested for the particular resource. The master resource object for each resource resides within only one of the lock manager units
106
,
116
and
126
.
The node on which a lock manager unit resides is referred to as the “master node” (or simply “master”) of the resources whose master resource objects are managed by that lock manager unit. Thus, if the master resource object for a resource R
1
is managed by lock manager unit
106
, then node
102
is the master of resource R
1
.
In conventional distributed lock manager systems, all requests for a resource go through the resource master of that resource. When the master of a resource exits normally or abnormally, the distributed lock manager system
132
has to select one or more of the remaining nodes to become the masters for the resources that were mastered by the terminated node. The process of rebuilding the master resource object at a new master node may involve collecting lock information for every remaining node in the distributed lock manager system
132
. Consequently, the task of rebuilding the master resource objects that resided on a failed node may be time consuming. Further, the amount of time required for the task increases as the number of nodes and/or the number of resources increases.
Unfortunately, during the process of rebuilding master resource objects on other nodes, all lock operations are suspended on the resources that are being remastered. Thus, when a node fails, the resources that were mastered by that node may become unavailable for an extended period of time. The extended unavailability of those resources may be unacceptable.
Based on the foregoing, it is clearly desirable to provide techniques for improving resource management. In particular, it is desirable to provide techniques that increase the availability of resources while the resources are being remastered.
SUMMARY OF THE INVENTION
Techniques are disclosed for managing access to a set of one or more resources that are accessible to a plurality of entities. In one embodiment, one primary resource master and one or more secondary resource masters are established for a given resource. Each resource master (whether primary or secondary) is assigned to be the master for the resource for a corresponding subgroup of entities of the plurality of entities. Each secondary resource master is assigned to a parent resource master, which may either be the primary resource master or another secondary resource master.
Each entity of the plurality of entities, upon seeking access to the resource, requests a lock on the resource from the resource master that is assigned to the subgroup that includes that entity. A secondary resource master communicates with its parent resource master for information regarding locks on a resource when the information maintained by that secondary resource master is insufficient for that secondary resource master to determine whether a particular lock on the resource can be granted.
When the primary resource master fails, the secondary resource masters may continue to manage and grant locks for the resource as long as the granting of the locks does not require information that was only on the primary resource master.
A resource master may be assigned to a subgroup of entities based on various factors, such as system configurations, similarity of tasks performed by each entity in the subgroup of entities, similarity of performance speed of each entity in the subgroup of entities, similarity of distances from each entity to the resource master to which the subgroup that includes the entities is assigned, etc.


REFERENCES:
patent: 5003464 (1991-03-01), Ely
patent: 5339427 (1994-08-01), Elko et al.
patent: 5459871 (1995-10-01), Van Den Berg
patent: 5612865 (1997-03-01), Dasgupta
patent: 5734909 (1998-03-01), Bennett
pat

Affiliated with

Also associated with

Rating

Using secondary resource masters in conjunction with a... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Using secondary resource masters in conjunction with a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Using secondary resource masters in conjunction with a... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3322733