System and method for automation of consistent lock management

A system and method for automation of consistent lock management, wherein a shared resource is accessed through an accessor object. An accessor object class includes at least one const read access function and one write access function. A const accessor object is received for read-only access of a shared resource. The compiler is enlisted to enforce lock selection.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the invention described herein pertain to the field of computer systems. More particularly, but not by way of limitation, one or more embodiments of the invention enable a lock management system and method.

2. Description of the Related Art

In a multi-threaded computing environment, resource objects must be shared between multiple threads. Applications running in a multi-threaded environment must be designed to avoid conflicts due to the access of shared resources, such as memory, hardware and data. Locking is a widespread technique used to address this concern. Locking prevents the use of a shared resource by more than one operation at a time. When an operation has an exclusive lock on a shared resource, it becomes unavailable to others. Concurrency control preserves resource consistency and resolves conflicts. In the management of shared data resources, locking secures the permission to access a data item during a transaction. Unlocking removes the permissions from the data item so that other processes and operations may move forward and access the shared resource in turn.

Proper locking implementation in an application running in a multi-threaded environment is complex. On one hand, under locking in an application is problematic because problems will occur that locking and lock management are designed to avoid. On the other hand, over locking can also create problems, such as deadlocking and performance degradation. Such problems are also exacerbated by poor coding practices. Lock implementation is an important and time-consuming part of application design. Improper implementation and management of locking may result in inefficiency and errors, such as deadlocks, race conditions, hanging, poor performance, exceptions, program termination, data corruption, and many other issues. Thus, improper lock management can result in high costs in terms of debugging, support and maintenance costs.

Lock escalation policies may be used to broaden access to a resource, such as a database. For example, a resource may be unlocked when a session is accessing the resource. Alternatively, one or more sessions may have a shared lock on a resource. Typically, a shared lock is granted when the session requests read access of the resource. A session may also have an exclusive lock on a resource. Typically, an exclusive lock is required when a modification, including a deletion and addition, is made to the resource. A lock management system may include refinement to enhance efficiency and consistency. For example, a lock management system may define a method for determining the priority of sessions which request a type of lock. Furthermore, an exclusive lock may be divided up into further locking states such that modifications are first cached before being written in a writing step.

In two-phase locking techniques, shared locks are used to provide read access to multiple transactions, while exclusive access is granted for write access. In the prior art, two-phase locking techniques use a lock manager which manages locks on all data items. A lock table may also be used to store the transaction, data item locked, and lock mode.

The granularity of lock management systems may vary. In coarse-grained locking, when a session is writing to a database, all other sessions are locked out until the transaction is completed. Fine-grained locking locks a tuple or attribute. In a database, granularity can range from a single field, a record, a table, one or more disc blocks, an entire table, or an entire database. Locking helps maintain the integrity of the data in a database by ensuring that the same data or related structures to the data are not modified in two different processes or operations concurrently. A lock management system for a database may be optimized to include functionality to implement multiple granularity levels in a single database lock management system.

When collections of objects are accessed by complex programs, they all need to be locked correctly and consistently. Even when a complex lock management system is available, code reuse and development typical for software projects tends to encourage developers to take an excessively pessimistic locking approach in order to avoid incurring severe support and maintenance costs due to insufficient locking. Currently, programmers have to choose lock types based on the context of the operation. Improper lock implementation by a programmer may result in problematic compiled code with poor performance.

Typically, a simple lock management system provides straightforward application design, implementation, and debugging. However, simple lock management systems typically do handle locking efficiently. On the other hand, an optimized lock management system provides more efficient access to shared resources, such as a database. However, software development becomes more complicated, and developers may not take advantage of the optimized system because of its complexity, especially in software projects involving multiple developers.

For at least the limitations described above there is a need for a system and method for automation of consistent lock management.

BRIEF SUMMARY OF THE INVENTION

One or more embodiments of the system and method enable a computer-readable storage medium comprising computer executable instructions for automation of consistent lock management. The instructions include requesting read access to a shared resource. The shared resource may be a database component.

A const accessor object corresponding to the shared resource is received. The const accessor object obtains a read access lock on the shared resource. The accessor object class includes at least one read access function and one write access function. The read access function may be a const function. When program code attempts write access of the shared resource through the const accessor object, the result is a compiler error. The const accessor object may be destructed when the access is complete. In one or more embodiments, the const accessor object communicates with the resource access manager and the resource to unlock the resource and any dependent resources.

One or more embodiments include instructions to promote a read access lock into a write access lock. The accessor object registers with a resource access manager, wherein the resource access manager tracks and manages accessor objects. The resource access manager may correspond to a set of logically related data, such as a customer database. The shared resource is accessed through the accessor object. A promotable accessor object initially obtains a promotable read lock on the shared resource. During its lifetime, the accessor object automatically detects the first attempt to perform a write operation and automatically requests promotion of the lock to a write lock. The described procedure automatically minimizes the amount of time the underlying resource is write-locked at the entry point.

The promotable accessor object may be destructed when the access is complete. In one or more embodiments, the promotable accessor object communicates with the resource access manager and the resource to unlock the resource and any dependent resources.

One or more embodiments of the system and method for automation of consistent lock management include instructions for requesting write access to a second shared resource. A second accessor object corresponding to the second shared resource is received. The second accessor object obtains a write access lock on the second shared resource. The second shared resource is accessed through the second accessor object.

In some programming languages, on-stack access objects allow the automation of lifetime management of object locking by automatically releasing locks when accessor objects are destroyed upon going out of scope. One or more embodiments of the system and method enable a computer system for automation of consistent lock management comprising at least one computer, a database and a computer-readable medium with program instructions.

Access to an element of the database is requested. A const accessor object corresponding to the element is received, wherein an accessor object class includes at least one read access function and one write access function, and wherein a read access lock on the element is obtained by the const accessor object. At least one read access function may be a const function. The element is accessed through the accessor object. The compilation of program code attempting write access of the element through the const accessor object results in a compiler error.

The accessor object is registered with a resource access manager, wherein the resource access manager tracks and manages accessor objects. The resource access manager may correspond to a set of logically related data, including a customer database.

The instructions of the computer-readable medium may further include requesting write access to a second element. A second accessor object corresponding to the second element is received, wherein the second accessor object obtains a lock on the second element. The second element is accessed through the second accessor object. The lock may be a read access lock, and the instructions may include promoting said read access lock to a write access lock. In one or more embodiments, promotion comprises obtaining a non-const accessor object corresponding to the const accessor object.

The accessor object may be destructed when access is complete. In one or more embodiments, the accessor object communicates with the resource access manager and the element to unlock the element and any dependent resources.

By communicating with the Resource Access Manager, accessor objects can ensure that objects of finer granularity that compose the accessed object are also locked with the correct lock type. When locks are promoted, accessor objects similarly ensure that locks of and objects including the accessed object are promoted if necessary.

DETAILED DESCRIPTION

A system and method for automation of consistent lock management will now be described. In the following exemplary description numerous specific details are set forth in order to provide a more thorough understanding of embodiments of the invention. It will be apparent, however, to an artisan of ordinary skill that the present invention may be practiced without incorporating all aspects of the specific details described herein. In other instances, specific features, quantities, or measurements well known to those of ordinary skill in the art have not been described in detail so as not to obscure the invention. Readers should note that although examples of the invention are set forth herein, the claims, and the full scope of any equivalents, are what define the metes and bounds of the invention.

FIG. 1is provided for purposes of illustrating a general-purpose computer100and peripherals which, when programmed as described herein, may operate as a specially programmed computer capable of implementing one or more methods, apparatus and/or systems of the invention. Processor107may be coupled to a bi-directional communication infrastructure such as Communication Infrastructure System Bus102. Communication Infrastructure102may generally be a system bus that provides an interface to the other components in the general-purpose computer system such as Processor107, Main Memory106, Display Interface108, Secondary Memory112and/or Communication Interface124.

Main memory106may provide a computer readable medium for accessing and executed stored data and applications. Display Interface108may communicate with Display Unit110that may be utilized to display outputs to the user of the specially-programmed computer system. Display Unit110may comprise one or more monitors that may visually depict aspects of the computer program to the user. Main Memory106and Display Interface108may be coupled to Communication Infrastructure102, which may serve as the interface point to Secondary Memory112and Communication Interface124. Secondary Memory112may provide additional memory resources beyond main Memory106, and may generally function as a storage location for computer programs to be executed by Processor107. Either fixed or removable computer-readable media may serve as Secondary Memory112. Secondary Memory112may comprise, for example, Hard Disk114and Removable Storage Drive116that may have an associated Removable Storage Unit118. There may be multiple sources of Secondary Memory112and systems of the invention may be configured as needed to support the data storage requirements of the user and the methods described herein. Secondary Memory112may also comprise Interface120that serves as an interface point to additional storage such as Removable Storage Unit122. Numerous types of data storage devices may serve as repositories for data utilized by the specially programmed computer system of the invention. For example, magnetic, optical or magnetic-optical storage systems, or any other available mass storage technology that provides a repository for digital information may be used.

Communication Interface124may be coupled to Communication Infrastructure102and may serve as a conduit for data destined for or received from Communication Path126. A Network Interface Card (NIC) is an example of the type of device that once coupled to Communication Infrastructure102may provide a mechanism for transporting data to Communication Path126. Computer networks such Local Area Networks (LAN), Wide Area Networks (WAN), Wireless networks, optical networks, distributed networks, the Internet or any combination thereof are some examples of the type of communication paths that may be utilized by the specially program computer system of the invention. Communication Path126may comprise any type of telecommunication network or interconnection fabric that can transport data to and from Communication Interface124.

To facilitate user interaction with the specially programmed computer system of the invention, one or more Human Interface Devices (HID)130may be provided. Some examples of HIDs that enable users to input commands or data to the specially programmed computer of the invention may comprise a keyboard, mouse, touch screen devices, microphones or other audio interface devices, motion sensors or the like, as well as any other device able to accept any kind of human input and in turn communicate that input to Processor107to trigger one or more responses from the specially programmed computer of the invention are within the scope of the system of the invention.

WhileFIG. 1depicts a physical device, the scope of the system of the invention may also encompass a virtual device, virtual machine or simulator embodied in one or more computer programs executing on a computer or computer system and acting or providing a computer system environment compatible with the methods and processes of the invention. Where a virtual machine, process, device or otherwise performs substantially similarly to that of a physical computer system of the invention, such a virtual platform will also fall within the scope of a system of the invention, notwithstanding the description herein of a physical system such as that inFIG. 1.

One or more embodiments of the invention are configured to enable the specially programmed computer of the invention to take the input data given and transform it into a source-independent server interface by applying one or more of the methods and/or processes of the invention as described herein. Thus the methods described herein are able to transform the raw input data, such as digital commands, to a source-independent server interface accepting origin-specific commands, using the system of the invention to result in an the server performing origin-specific commands arranged to preserve the independence of the, using the specially programmed computer as described herein. Particularly, the system of the invention may be programmed to acquire an object containing commands for execution and interpreting said commands in light of an origin-independent interface.

FIG. 2is a block diagram of a system in accordance with one or more embodiments of systems and methods for automation of consistent lock management. System200may be implemented in a single application on a single computer, or over multiple applications and multiple computers. System200includes resources202-204. Resources202-204are shared resource objects. Resources202-204may reside on the same computer system or different computer systems, such as memory, hardware or data. In one or more embodiments, resources202-204are data objects in a database system. Embodiments of the system and method for automation of consistent lock management may handle resources on a fine-grained level, coarse-grained level, or a combination. Each of resources202-204can represent a single data object or a group of data objects. A grouping of objects may be logically or physically related.

Operation222runs within system200. Operation222requires access to resources202-204. Access to resources202-204is handled through accessor objects212-216. Access includes read access and write access. In one or more embodiments of the system, write access includes permission to read, modify, delete and add a resource. Operation222communicates with accessor objects212-216to request access to resources202-204. From the standpoint of the developer creating operation222, accessor objects212-216may be viewed as handles or wrappers to resource202-204.

Accessor objects212-216may comprise an identifier which identifies the resource associated with each accessor object. The identifier for the resource may comprise any variable type, such an integer, double, character, float, string, vector, or an object, and/or at least one pointer to any such type. The accessor object may also comprise multiple variables or data structures for identifying the associated access-controlled resource. Operation222may request an accessor object corresponding to a resource using an identifier for the specified resource. For example, an operation may request an accessor object from another component of the system, such as the Resource Access Manager, or any other component of system200, including components not described in this application. Alternatively, operation222may directly instantiate a new accessor object using the identifier for the resource. Operation222may either be provided with a new instance of an accessor object or an existing accessor object.

Accessor objects212-216communicate with Resource Access Manager280and resource objects202-204. By communicating with Resource Access Manager280and resources202-204, resources202-204are able to lock resources202-204with the correct lock type suitable for the requested access by operation222.

Accessor objects212-216and locks obtained via accessor objects212-216are tracked and managed by Resource Access Manager280. In one or more embodiments of the system, one Resource Access Manager280is used for each set of logically related resources, such as a subset of database containing related data. In one or more embodiments, the shared resources are contained in a master database, and one Resource Access Manager280is used for each customer database stored within the master database.

In one or more embodiments of the system and method for automation of consistent lock management, a const accessor object216is used when read only access to resource204is required. This allows the compiler to be enlisted in the automation of consistent lock management. For example, if a developer writes code for operation222which requests read-only const accessor object216to perform a write access action on resource204, the accessor object may be programmed such that the compiler will not compile the code. The accessor object may also be programmed such that the lock is released upon the destruction of the object upon going out of scope, automating lock release when supported by the programming language in which the accessor object is implemented.

FIG. 3provides a diagram of process steps for an operation in accordance with one or more embodiments of systems and methods for automation of consistent lock management. Process300starts at step302. Processing continues to step304, where the operation requests access to a resource.

Processing continues to step306, where the operation receives an accessor object which corresponds to the resource. The accessor object will communicate with the Resource Access Manager and the resource to lock the resource and its subcomponents with the right lock types based on the request type of the operation in step304. The Resource Access Manager may use its knowledge of existing accessor objects to optimize locking. In one or more embodiments of the system, one Resource Access Manager is used for each set of logically related resources, such as a subset of database containing related data. In one or more embodiments, the shared resources are contained in a master database, and one Resource Access Manager is used for each customer database stored within the master database.

The operation may create an accessor object based on an identifier for the resource. The identifier for the resource may comprise any variable type, such an integer, double, character, float, string, vector, or an object, and/or at least one pointer to any such type. The accessor object may also comprise multiple variables or data structures for identifying the associated access-controlled resource. Alternatively, the operation may request the accessor object corresponding to the resource using an identifier for the resource. For example, the operation may request an accessor object from the Resource Access Manager, or another part of the system not described in this application. The operation may be provided a new instance of an accessor object or an existing accessor object.

Processing continues to step308, where the operation accesses the resource via the resource object. For example, the operation may call functions of the resource object which, provide access to the resource. In one or more embodiments of the system and method for automation of consistent lock management, a const accessor object is received by the operation when read-only access to the resource is requested. This allows the compiler to be enlisted in the automation of consistent lock management. When the accessor object is properly designed, the compiler will not compile a program which requests a read-only (const) accessor object to perform an operation outside of this permission.

Processing continues to decision step310, where it is determined continued access to the resource is required. If continued access to the resource is required, processing continues to step308. Otherwise, processing is continued to step312, where the operation notifies the accessor object that access is complete. In one or more embodiments, the accessor object communicates with the Resource Access Manager and the resource to unlock the resource and any dependent resources. The accessor object may also destruct after receiving the notification at312and properly notifying any other system components, such as the Resource Access Manager that access to the resource specific to this accessor object is no longer required by the specific operation. Processing continues to step314, where process300terminates.

FIG. 4provides a diagram of process steps for an accessor object in accordance with one or more embodiments of systems and methods for automation of consistent lock management. At the start of process400, an operation has received the accessor object described. Process400starts at step402and continues to step404. At step404the accessor object receives a request from an operation to access a resource.

Processing continues to step406, where the accessor object communicates with the Resource Access Manager and the resource to obtain the correct lock type to access the resource. In one or more embodiments of the system, one Resource Access Manager is used for each set of logically related resources, such as a subset of database containing related data. In one or more embodiments of the invention, the shared resources are contained in a master database, and one Resource Access Manager is used for each customer database stored within the master database.

In one or more embodiments of the method, the operation may only request a read access if the accessor object is a const accessor object. Otherwise, the program code for the operation would fail to compile. To ensure that the program code compiles, the operation must request and receive the proper type of accessor object in steps304-306. Processing continues to step408, where the request is accepted. Note that this is not a decision step because only code comprising requests which will be accepted will compile.

Processing continues to decision step410, where it is determined whether the current lock type is adequate for the accessor object to perform the resource access request from the operation, or if the current lock needs to be promoted. This decision is relevant to the case where of a non-const accessor object, which is capable of receiving both read and write requests from the operation. If the current lock type is adequate, processing continues to step414. Otherwise, if the current lock type needs to be promoted, processing continues to step412, where the accessor object communicates with the Resource Access Manager and the resource to promote the lock that the accessor object has on the resource. A person of ordinary skill in the art would appreciate that there are many existing techniques to optimize lock promotion as described in step412. Processing continues to step414.

At step414, the accessor object performs the request by accessing the resource and returning or otherwise communicating the result of the access to the operation. For example, the accessor object may execute functions calls initiated by the resource object.

Processing continues to decision step416, where it is determined whether to terminate the accessor object. For example, the accessor object may be terminated by destruction when access is no longer required by the operation. In other embodiments, termination does not necessarily result in the termination of the accessor object, only the relationship between the accessor object and the operation. If it is determined that the accessor object may be terminated, processing continues to step418. Otherwise, processing continues to step408to begin the processing of another resource access request from the operation.

At step418, the accessor object notifies the Resource Access Manager to end the relationship between the accessor object and the operation. In one or more embodiments, the accessor object communicates with the Resource Access Manager and the resource to unlock the resource and any dependent resources. Processing continues to optional step420, where the accessor object is destructed after properly notifying any other system components, such as the Resource Access Manager that access to the resource specific to this accessor object is no longer required by the specific operation. Processing continues to step422, where process400terminates.

FIG. 5provides an interaction diagram in accordance with one or more embodiments of systems and methods for automation of consistent lock management. At step552, operation502requests access to resource202through accessor object212. In one or more embodiments of the system and method, the system is configured such that the compiler enforces the request type, limiting the request to a read access request for a const accessor object.

At step554-556, accessor object212communicates with Resource Access Manager280to obtain an appropriate lock for the access requested by operation502. In one or more embodiments of the system, one Resource Access Manager280is used for each set of logically related resources, such as a subset of database containing related data. In one or more embodiments of the invention, the shared resources are contained in a master database, and one Resource Access Manager280is used for each customer database stored within the master database.

At step558, resource202is locked by accessor object212. At step560, resource202responds to lock request558with a confirmation. At step562, Resource Access Manager280is notified by accessor object212that resource202is now locked, giving operation502safe access to resource202through accessor object212.

At steps564-566, accessor object212communicates with resource202to perform the request from operation502(which was communicated at step552) from operation502. At step568, any appropriate response is returned or otherwise communicated to operation502by accessor object212.

When operation502is ready to release the lock on resource202through accessor object212, operation502sends a release request to accessor object212. Accessor object212communicates with Resource Access Manager280at steps581-582to update Resource Access Manager280. At steps583-584, accessor object212communicates with resource202, releasing the lock on resource202. At step585, Resource Access Manager280is notified that resource202is unlocked. At step586, accessor object212returns control to operation502.

FIG. 6provides an interaction diagram in accordance with one or more embodiments of systems and methods for automation of consistent lock management.FIG. 6illustrates steps for operation602to access resource202through accessor object612when the process is initiated before operation502has released the lock on resource202through accessor object212.FIG. 6describes a situation where operation502and operation602both require mutually exclusive access to resource202. Steps involving operation502fromFIG. 5are shown in dotted lines to indicate an exemplary order of these steps with reference to steps652-664involving operation602.

At step652, operation602requests access to resource202through accessor object612. In one or more embodiments of the system and method, the system is configured such that the compiler enforces the request type, limiting the request to a read access for a const accessor object.

At step654, accessor object212communicates with Resource Access Manager280to obtain an appropriate lock for the access requested by operation502. In one or more embodiments of the system, one Resource Access Manager280is used for each set of logically related resources, such as a subset of database containing related data. In one or more embodiments of the invention, the shared resources are contained in a master database, and one Resource Access Manager280is used for each customer database stored within the master database.

Resource Access Manager280successfully responds to accessor object at612at step656, indicating that accessor object612may proceed with the locking process. Although step656, which communicates a success, occurs after step585, one of ordinary skill in the art would appreciate that Resource Access Manager may notify accessor object612before step585. For example, Resource Access Manager280may notify accessor object612of any other synchronization event, such as an expected waiting period or a failure to obtain a lock at the time of the request. Likewise, accessor object612may notify operation602of such events.

At step658, accessor object612requests of resource202that it lock. At step660, resource202confirms to612that it is locked. At step662, Resource Access Manager280is notified by accessor object212that it locked resource202, giving operation602safe access to resource202through accessor object612. At step664, accessor object612forwards request652to the resource.

FIG. 7provides pseudocode generally describing class objects in accordance with one or more embodiments of systems and methods for automation of consistent lock management.FIG. 7shows exemplary high-level pseudocode describing one or more implementations of a system and method for automation of consistent lock management which take advantage of native object-level modifiability controls provided by some object-oriented programming languages to implement compiler-enforced lock management. A person of skill in the art would recognize thatFIG. 7merely provides an outline of a portion of a system and method for automation of consistent lock management, wherein the system and method take advantage of native object-level modifiability controls provided by some object-oriented programming languages to implement compiler-enforced lock management.

Pseudocode700includes an operation described in the main function at lines702-712. The main function comprises an exemplary usage of accessor objects to access one or more shared resources in one or more embodiments of a system which implements the automation of consistent lock management. At line704, ConstAccessor a1is instantiated. The value of a1is set to the value returned by function GetConstAccessor( ) In exemplary pseudocode at line704, GetConstAccessor is passed a string, “list of fields”. One or more embodiments of GetAccessor( ) returns an Accessor based on arguments comprising information which identifies a shared resource. ConstAccessor a1is used by the operation (main( )) to safely access the identified shared resource. Information which identifies the shared resource may comprise any variable type, such an integer, double, character, float, string, vector, or an object, and/or at least one pointer to any such type. Multiple variables or data structures may also be used for identifying the associated access-controlled resource. The identifying information may include relational or other indexes which may identify a shared resource within a database. The identified resource may vary in scale in granularity. Although a string comprising a list of fields is described at line704, any variable type and structure may be used.

At line706, ConstAccessor a1is used by the operation (main( )) to access the shared resource corresponding to ConstAccessor a1by using a const function of Accessor, GetData( ). The Accessor class comprises at least one const function which provides read access to the shared resource. A compiler will accept the use of a read access function with either a ConstAccessor object or an Accessor object. Before read access of the shared resource, ConstAccessor a1ensures that a read lock on the shared resource has been obtained. ConstAccessor a1may lock the resource upon creation of ConstAccessor a1.

At line708, Accessor a2is instantiated. The value of a2is set to the value returned by function GetAccessor( ). In exemplary pseudocode at line708, GetAccessor is passed a string, “list of columns”. One or more embodiments of GetAccessor( ) returns an Accessor based on arguments comprising information which identifies a shared resource. Accessor a2is used by the operation (main( )) to safely access the identified shared resource. Information which identifies the shared resource may comprise any variable type, such an integer, double, character, float, string, vector, or an object, and/or at least one pointer to any such type. Multiple variables or data structures may also be used for identifying the associated access-controlled resource. The identifying information may include relational or other indexes which may identify a shared resource within a database. The identified resource may vary in scale in granularity. Although a string comprising a list of columns is described at line708, any variable type and structure may be used.

At line710, Accessor a2is used by the operation (main( )) to access the shared resource corresponding to Accessor a2by using a const function of Accessor, GetData( ). The Accessor class comprises at least one const function which provides read access to the shared resource. A compiler will accept the use of a read access function with either a ConstAccessor object or an Accessor object. Before read access of the shared resource, Accessor a2ensures that a read lock on the shared resource has been obtained. Accessor a2may lock the resource with an initial level of locking upon creation of Accessor a2. In one or more embodiments, the initial level of locking is read access locking.

At line710, Accessor a2is used to access the shared resource corresponding to Accessor a2by using a function of Accessor which enables write access, ModifyData( ). The Accessor class comprises at least one function which provides write access of the shared resource to the shared resource. A compiler will only accept programming code involving access of a non-const function when the access is through an Accessor object. When program code attempts write access of the shared resource through a ConstAccessor object, a compiler error occurs. This leads to the automation of consistent lock management by taking advantage of native object-level modifiability controls to implement compiler-enforced lock management.

Function GetConstAccessor(“resource”) at line714returns a ConstAccessor object, as requested. Function GetAccessor(“resource”) at line716returns an Accessor object, as requested. Functions GetConstAccessor( ) and GetAccessor( ) allow the main( ) operation to access shared resources associated with the Accessor or ConstAccessor object returned. Both GetConstAccessor( ) and GetAccessor( ) take arguments comprising information which identifies a shared resource. Information which identifies the shared resource may comprise any variable type, such an integer, double, character, float, string, vector, or an object, and/or at least one pointer to any such type. Multiple variables or data structures may also be used for identifying the associated access-controlled resource. The identifying information may include relational or other indexes which may identify a shared resource within a database. The identified resource may vary in scale in granularity.

The const function Accessor::GetData( ) appears at line718. The function Accessor::ModifyData( ) appears at line720. A compiler will allow access of a const read access function of Accessor by either a ConstAccessor object or an Accessor object. However, a compiler will only allow access of a write access function by an Accessor object, provided that the write access function is not a const function. Before accessing the shared resource, ConstAccessor objects and Accessor objects ensure that a proper lock on the shared resource has been obtained.

The function ModifyData( ) includes promoteRead( ) at line722and modify( ) at line724. In one or more embodiments, even though an Accessor object handles both read and write access of a shared resource, the Accessor object will only obtain a write lock when it is required to perform a modification on the shared resource. For example, when a const (read) function of Accessor a2is called at line710, only a read lock is obtained by Accessor a2. When a non-const (write) function “ModifyData( )” of Accessor a2is called at line712, promoteRead( ) at line722executes before modify( ). PromoteRead( ) includes code which checks the lock type and promotes the lock on the shared resource, if necessary before modify( ) performs the write-access operation on the shared resource. A person of skill in the art would recognize that, functions promoteRead( ) and modify( ) are used to represent blocks of programming instructions which perform the tasks described, the programming instructions embodied by promoteRead( ) and modify( ) may be implemented inline within ModifyData( ).

Line717describes a Constructor for an Accessor object. Line726describes a Destructor for an Accessor object. In one or more embodiments, each Accessor and const Accessor object notifies a resource access manager of its creation, destruction, and changes in lock status. In one or more embodiments, the shared resources are contained in a master database, and one Resource Access Manager is used for each customer database stored within the master database.

In one or more embodiments of the systems and methods for automation of consistent lock management, an object-oriented programming language used to implement the pseudocode described inFIG. 7. ConstAccessor and Accessor objects may be defined a single class. A keyword, such as the “const” keyword of C++, may be utilized to implement features described inFIG. 7which take advantage of native object-level modifiability controls provided by some object-oriented programming languages to implement compiler-enforced lock management.