Apparatus for database record locking and method therefor

[0002] The invention relates in general to data processing systems for database management, and in particular, to a system for locking database records in a multi-threaded, distributed, data processing environment.

[0003] Database management systems (or other file management system) in a multi-threaded, or similar multiple client data processing system environment must implement a scheme for avoiding record collisions or contentions. That is, the database management system (DBMS) must incorporate a scheme for locking records so that a second client does not access the record during the pendency of an operation on the records by the first client.

[0004] Typically a software component which may be referred to as a “resource manager” controls which records are locked. The resource manager may track, for each record, whether the record is locked, including a type of lock such as a shared lock or exclusive lock, for the record. Consequently, the resource manager may, for a realistically sized database, be complex, with the locking and unlocking of records involving a multiplicty of decision paths. Thus, there is a need in the art for more efficient lock management systems.

[0005] The aforementioned needs are addressed by the present invention. Accordingly there is provided a method for database record locking. A lock state is selectively set in response to a locking operation request. The lock state constitutes a class in an object-oriented locking service architecture. A locking operation corresponding to the locking operation request is performed on one or more records. The locking operation is implemented by a method of a lock state class in the object-oriented locking service architecture, the lock state class corresponding to a current lock state.

[0006] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.

[0007] For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0008] FIG. 1 illustrates, in block diagram form, a database system in accordance with an embodiment of the present invention;

[0009] FIG. 2 illustrates, in block diagram form, a data processing system which may be used in conjunction with the embodiment of FIG. 1;

[0010] FIG. 3 schematically illustrates an object-oriented architecture for managing record blocking in accordance with the principles of the present invention;

[0011] FIG. 4 illustrates a state diagram for the transitioning of states in accordance with the architecture of FIG. 3;

[0012] FIG. 5 illustrates, in flowchart form, a record locking methodology in accordance with an embodiment of the present invention; and

[0013] FIG. 6 illustrates in further detail a database system in accordance with the principles of the present invention.

[0014] In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. For example, database records maybe identified by particular numerical values, however it would be recognized by those of ordinary skill in the art that the present invention may be practiced without such specific details. Furthermore, the present invention, for clarity, may be described in the context of the Java™ programming language, however, the present invention may be practiced in other programming language context in addition to Java™. In other instances, well-known circuits have been shown in block diagram form in order not to obscure the present invention in unnecessary detail.

[0015] Refer now to the drawings wherein depicted elements are not necessarily shown to scale and wherein like or similar elements are designated by the same reference numeral through the several views.

[0016] Referring to FIG. 1 there is illustrated a database system 100 in accordance with the principles of the present invention. System 100 includes one or more database clients 102, labeled CA, CB, . . . , CX. Access to database (DB) 104 is mediated via database server 106 which includes locking service 108 in accordance with the principles of the present invention. Clients 102 may be coupled to database server 106 via network 110, may be a local machine or via a network which may be a local area network (LAN), wide area network (WAN), or the Internet.

[0017] Refer now to FIG. 2 which illustrates a database server 106 in accordance with the principles of the present invention, in further detail. Server 106 may include a central processing unit (CPU) 210 coupled to various other components by system bus 212. An operating system 240 runs on CPU 210 and provides control and coordinates the function of the various components in FIG. 2. Application 250 includes locking service 108, FIG. 1, in accordance with the principles of the present invention and which will be described further in conjunction further with FIGS. 3-6 hereinbelow. Application 250 runs in conjunction with operating system 240, which coordinates the internal functions of database server 106, as would be understood by those of ordinary skill in the art. Additionally, read only memory (ROM) 216 is coupled to system bus 212 and includes a basic input/output system (BIOS) that control certain basic functions of server 106. Random access memory (RAM) 214, disk adapter 218 and communications adapter 234 are also coupled to system bus 212. It should be noted that software components including operating system 240 and application 250 are loaded into RAM 214 which is the computer systems main memory. Disk adapter 218 may be a Universal Serial Bus (USB) or other adapter that communicates with disk units 220. It is noted that the program of the present invention may reside in disk unit 220 and loaded into RAM 214 by operating system 240, as required. Communications adapter 234 interconnect bus 212 with a network, such as network 110, FIG. 1.

[0018] Implementations of the invention include implementations as a computer system programmed to execute the method or methods described herein, and as a computer program product. According to the computer system implementations, sets of instructions for executing the method or methods are resident in the random access memory 214 of one or more computer systems configured generally as described above. And to require by server 106, the set of instructions maybe stored as a computer program product in another computer memory, for example in disk drive 220 (which may include a removable memory such as an optical disk or floppy disk for eventual use in disk drive 220). Furthermore, the computer program product can also be stored in another computer and transmitted when desired to the work station by a network or by an external network such as the Internet. One skilled in the art would appreciate that the physical storage of the sets of instructions physically changes the medium upon which it is stored so that the medium carries computerable information. The change may be electrical, magnetic, chemical or some other physical change.

[0019] Refer now to FIG. 3 illustrating an object-oriented locking service architecture 300 for providing locking services in accordance with the principles of the present invention. RecordLockManager class 302 manages transitions between lock states of the database, which states will be described further below. Additionally, RecordLockManager class 302 includes methods for handling the locking and unlocking of database records. RecordLockManager class 302 implements RecordLockContext 304. RecordLockContext 304 is an interface class. An interface class defines methods that are implicitly abstract. Thus, RecordLockManager 302 may provide an implementation of a changeState ( ) method for managing state transitions, defined by RecordLockContext 304. (In the Java™ programming language context, an interface class replaces the multiple inheritance of other object-oriented programming languages such s C++.)

[0020] RecordLockManager 302 also contains a RecordLockState object 303 representing the current lock state of the database. RecordLockState object 303 maybe an instance of one of three state classes, NoneLockedState class 306, SomeLockedState class 308 and AllLockedState class 310. RecordLockState object 303 may change as the database transitions into different states, as discussed below. Note that RecordLockState object 303 may be a singleton, that is a single instantiation of a class, for the entire system. All three classes implement RecordLockState interface 312 defining methods for locking and unlocking records, which are implemented by each NoneLockedState class 306, SomeLockedState class 308 and AllLockedState class 310.

[0021] The NoneLockedState class 306 represents a state in which all records are freely available in the database. (This may be the default initial state of the database when a server in accordance with the principles of the present invention starts.) AllLockedState class 310 represents a state in which the entire database is locked. SomeLockedState class 308 represents a state in which one or more individual records in the database are locked. SomeLockedState class 308 may include hashtable 314, which contains a hash of all of the records in the locked state.

[0022] The current lock state of the database, represented by RecordLockState object 303, can transition to a different one of NoneLockedState, SomeLockedState or AllLockedState when either a lock or unlock request is called on the corresponding one of NoneLockedState class 306, SomeLockedState class 308 or AllLockedState class 310. (Note that a lock request and unlock request may collectively be referred to as a locking operation request.) Locking operation requests may be received from a client, such as one of clients 102, FIG. 1.

[0023] The transitions between different states may be understood by referring now to FIG. 4 illustrating a state diagram in accordance with the principles of the present invention. Consider first NoneLockedState class 306. Calling lock( ) on NoneLockedState class 306 may transition the state to either AllLockedState 310 or SomeLockedState 308. If the lock is called with a valid record number (indicated by “γ” in FIG. 4) then the state transitions to SomeLockedState 308, transition 402. Records may be identified by a unique identifier, for example, a record number which may be in a range from zero to a predetermined maximum record number. However, other record numbers may be used in an alternative embodiments of the present invention, and these would be understood by those of ordinary skill in the art to fall within the spirit and scope of the present invention. Additionally, a particular identifier may be associated with the entire database. In FIG. 4, the record number value “−1”, denotes the entire database. Calling lock(−1) on NoneLockedState 306 transitions the state to AllLockedState 310, transition 404. Calling unlock( ) on NoneLockedState 306 results in an invalid transition, and an exception may be thrown, transition 406.

[0024] Consider now transitions from SomeLockedState 308. If a lock request is made on a record, γ, that is, a lock request as called on SomeLockedState 308, the state remains in SomeLockedState class 308, transition 408. Requesting a lock on the entire database by calling lock (−1) on SomeLockedState 308 is invalid, transition 410. Additionally, an unlock request may be made on SomeLockedState class 308. If the hash table, such as hash table 314, FIG. 4 is empty as a result of the unlock operation, a transition of the current state from SomeLockedState class 308 to NoneLockedState 306 results, transition 412. (The operations on the hashtable will be described in conjunction with FIG. 5 hereinbelow.)

[0025] Now consider locking and unlocking requests called on AllLockedState class 310. If an unlock request on the entire database is called on AllLockedState class 310, a transition to NoneLockedState 306 results, transition 414. Calling a lock on AllLockedState class 310 results in an invalid transition, and again, an exception may be thrown, transition 416.

[0026] Refer now to FIG. 5 illustrating, in flow chart form, a locking methodology 500 in accordance with the principles of the present invention. The steps of methodology 500 may be performed by one or more of the methods of the classes in the objected oriented architecture described hereinabove in conjunction with FIG. 3. This will be discussed in further detail below.

[0027] Initialization of the database is performed in steps 502 and 504. In step 502, the database is started. In step 504, the current state is initialized to NoneLockedState. In step 506, locking methodology 500 enters a locking event loop, that is active while the database is active, and terminates, in step 508, when the database is inactive.

[0028] While in the locking event loop, locking requests from database clients, such as clients 102, FIG. 1, are handled in steps 510 and 512, respectively. Lock and unlock requests may be handled by RecordManager.lock( ) and RecordLock.unlock( ) methods in an embodiment in accordance with the inventive principles of object-oriented architecture 300, FIG. 3. If neither a lock or unlock request is receiver, methodology loops between steps 506, 510 and 512.

[0029] If, in step 510, a lock request is received, it is determined, in step 514, if the current state is lockable. If not, in step 516, an exception is thrown. Recall that, referring to FIG. 4, a lock request on the AllLockedState is invalid. If the current state is lockable, in step 518 it is determined if the record number corresponds to the record number representing the entire database, which may be −1, for example. If the lock request is for the entire database, the current state transitions to the AllLockedState, in step 520. The current state may be changed in an embodiment accordance with the architecture of FIG. 3 by the RecordManager.changeState( ) method which implements the changeState( ) method defined in RecordLockContext 304, FIG. 3.

[0030] If, however, the lock request is not for the entire database, then the lock request is directed to a particular record, which as previously discussed, may be identified by a record number, for example. In step 522, methodology 500 enters a loop pending availability of the record. If the record is not available (that is, the record is currently locked by another client), in step 524, methodology waits for an unlock notification. (In an embodiment of the present invention in accordance with architecture 300, FIG. 3, step 522 may be performed by detecting the current state to be an AllLockedState object, or a SomeLockedState object with a hashtable entry corresponding to the record lock request.) When the record becomes available, methodology 500 breaks out of the loop via the “Yes” branch in step 522.

[0031] If (step 528), the current state is SomeLockedState, then, as described hereinabove, the lock state remains SomeLockedState, and in step 530, the hashtable is updated to include the record number or other identifier of the record corresponding to the lock request, thereby locking the record. (This may be performed by the SomeLockedState.lock( ) method implemented by SomeLockedState class 308, FIG. 3, which may be passed the request by RecordManager.lock( ).

[0032] Otherwise, in step 532, the state transitions to SomeLockedState. (Recall that a valid lock request may also be called on a current NoneLockedStated.) Step 532 may be performed by the RecordManager.changeState( ) method, as described above, and the lock request passed to the SomeLockedState.lock( ) method in an embodiment in accordance with object-oriented architecture 300, FIG. 3, to update the hashtable, step 530, as previously discussed. Methodology 500 returns to step 506 to continue to process lock and unlock requests.

[0033] Returning to step 512, if an unlock request is received, in step 532 it is determined if the current state is NoneLockedState. If so, in step 534, an exception is thrown. Recall that, referring to FIG. 4, an unlock request on the NoneLockedState is invalid.

[0034] Otherwise, it is determined (step 536) if the current state is AllLockedState. If so, the current state transitions to the NoneLockedState, and methodology 500 returns to step 506.

[0035] In an embodiment of the present invention, each lock and unlock request maybe associated with a separate thread of execution. This may be understood by referring to FIG. 6 which illustrates the database system of FIG. 1 in further detail. Database elements may be represented in the database server, such as server 106, by a static data object 602, of which there may be a single instance. Methods of static data object 602 implement actions on database elements, including the locking and unlocking of records, which may be effected via locking service 108, in accordance with the principles of the present invention. Each request from a client, such as one of clients 102 may be mediated by a separate thread of execution (or simply, execution thread), denoted T₁, T₂, . . . , T_nin FIG. 6. (Threads of execution also may be referred to a execution threads, or simply, threads.) Each thread may invoke the methods of static data object 602 through an instance of a corresponding local data object 604. Additionally, each locked record may be associated with the thread that “locked” it.

[0036] Returning to FIG. 5, in step 538, it is determined if the thread requesting the unlocking of the record “owns” the record, that is, if the thread associated with the request locking the record is the unlocking thread. If not, in step 540, an exception is thrown. Otherwise, the record is unlocked, step 542. Step 542 may be performed by SomeLockedState.unlock( ), in an embodiment in accordance with the object-oriented architecture of FIG. 3.

[0037] In step 544, the record number, or other identifier, of the unlocked record is deleted from the hashtable. In step 546, it is determined if the hashtable is empty. If so, there are no locked records, and in step 548, the current state transitions to NoneLockedState. Otherwise, the current state is unchanged, and step 548 is bypassed.

[0038] Recall that, as discussed in conjunction with steps 522 and 524, a client may be waiting for the record to become available. In step 550, all threads are notified that the record has been unlocked, and methodology 500 returns to step 506.

[0039] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.