WO2002010978A2 - Procede, systeme et structures de donnees permettant de mettre en oeuvre des bases de donnees imbriquees - Google Patents

Procede, systeme et structures de donnees permettant de mettre en oeuvre des bases de donnees imbriquees Download PDF

Info

Publication number
WO2002010978A2
WO2002010978A2 PCT/NO2001/000304 NO0100304W WO0210978A2 WO 2002010978 A2 WO2002010978 A2 WO 2002010978A2 NO 0100304 W NO0100304 W NO 0100304W WO 0210978 A2 WO0210978 A2 WO 0210978A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
data structure
lock
hierarchical level
database
Prior art date
Application number
PCT/NO2001/000304
Other languages
English (en)
Other versions
WO2002010978A9 (fr
WO2002010978A3 (fr
Inventor
Ole Jorgen Anfindsen
Original Assignee
Xymphonic Systems As
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/628,728 external-priority patent/US6751617B1/en
Priority to AU7286301A priority Critical patent/AU7286301A/xx
Priority to CA002416909A priority patent/CA2416909A1/fr
Priority to AU2001272863A priority patent/AU2001272863B2/en
Priority to MXPA03000756A priority patent/MXPA03000756A/es
Priority to BR0112967-8A priority patent/BR0112967A/pt
Application filed by Xymphonic Systems As filed Critical Xymphonic Systems As
Priority to EP01952068A priority patent/EP1323071A2/fr
Priority to JP2002515631A priority patent/JP2004505380A/ja
Priority to KR10-2003-7001266A priority patent/KR20030047996A/ko
Publication of WO2002010978A2 publication Critical patent/WO2002010978A2/fr
Publication of WO2002010978A3 publication Critical patent/WO2002010978A3/fr
Publication of WO2002010978A9 publication Critical patent/WO2002010978A9/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details

Definitions

  • the present invention relates generally to database management systems.
  • the invention is more particularly related to data management systems and transaction processing systems that utilize a lock manager for protecting database resources from incompatible uses.
  • the invention is still further related to the manner of implementing a database management system which allows the use of nested databases based on computer data structures which are stored in a memory.
  • the invention is related and applicable to any system which provides concurrent access to shared data.
  • ACID Automaticity, Consistency, Isolation, Durability
  • Atomicity means that either the results of the transaction (i.e., changes to the database) are all properly reflected in the database, or none of them are.
  • a transaction is said to commit or abort.
  • a transaction commits all changes made to the database by the transaction are durably stored, leaving the database in a consistent state.
  • a transaction aborts any changes made to the database by the transaction are backed out, once again leaving the database in a consistent state.
  • Consistency means that each transaction commits only legal results to the database. Thus a transaction must bring the database from one consistent state to another consistent state.
  • Isolation means that events within a transaction must be hidden from other transactions running concurrently. Concurrent transactions must not interfere with each other. They execute as if they had the database to themselves.
  • Durability means that once a transaction has been completed and has committed its results to the database, the system must guarantee that these results survive any subsequent malfunctions.
  • a memory including data structures, a method, system, and computer program product which allow concurrency control and locking of data in a multiuser environment.
  • a database or subdatabase associated with that transaction.
  • This data structure related to the transaction may be referred to as a transaction control block.
  • Data structures, which are referred to herein as database control blocks, indicate which database or subdatabase relates to a data item.
  • a lock control block and/or a lock request block.
  • the association among the various data structures allows the implementation of the concept of nested databases, subdatabases or virtual databases.
  • the data structure arrangement preferably allows there to be a determination as to the context database of a particular transaction, and also the subdatabases under that transaction.
  • the data structure related to the transaction may also contain references to granted and pending lock requests which may be represented by the data structures relating to locks of the data.
  • the data structures related to the virtual databases, the database control blocks, are referenced by the locking data structures so that it can be determined to which database or subdatabase the lock relates.
  • a memory for storing data for access by a data processing system.
  • This data is not necessarily the data item which the end user ultimately desires, but may be the data related to the data structures indicating the locking and subdatabase information.
  • the memory includes a data structure including information of a transaction.
  • This data structure is preferably implemented as a transaction control block.
  • the memory further includes a data structure including information of a lock of data of the transaction.
  • This data structure may be referred to as a lock control block and/or a lock request block.
  • there is a plurality of data structures including information of a plurality of databases. These data structures related to the databases may be referred to as database control blocks.
  • the database control blocks are utilized to associate a particular database or subdatabase with a lock and transaction, or vice versa, in order to properly control the nested or subdatabases.
  • the invention also relates to the creation and use of the data structures which implement the concept of the nested or subdatabases.
  • a method of indicating that a data item is locked includes the steps of creating in a first hierarchical level, a data structure indicating that the data item is locked by a first transaction associated with the first hierarchical level. Further, the method includes a step of creating, at a second hierarchical level, a data structure indicating that the data item is locked by a second transaction associated with a second hierarchical level.
  • the above steps create a hierarchy of locking controlled data structures, such as lock control blocks. Each level in the hierarchy may be utilized by a different database, subdatabase, or virtual database.
  • step (a) determining if a lock for the data item exists at a first hierarchical level, and (b) creating a lock for the data item at the first hierarchical level when step (a) determines that the lock for the data item does not exist.
  • step (c) for determining if a lock for the data item exists at a second level when step (a) determines that the lock for the data item does not exist.
  • step (d) of creating a lock on the data item, when a lock on the data item does not exist at the second hierarchical level.
  • the invention includes a system having various means for carrying out the above functionality. Moreover, the invention still further includes a computer program product including executable instructions for carrying out the methodology of the invention.
  • Figure 1 is a block diagram of database management system implementing the present invention
  • Figure 2 illustrates data structures for keeping track of resources which are divided into subdatabases
  • Figure 3 illustrates a plurality of linked lock control blocks and lock request blocks
  • FIG. 4 illustrates data structures including subdatabase lock control blocks ("SLCBs") which are utilized to establish locks for data items within subdatabases;
  • SLCBs subdatabase lock control blocks
  • Figure 5 illustrates that each transaction belongs to a particular database or subdatabase
  • FIG. 6 illustrates that in this particular embodiment, a transaction can only access resources in its own database or subdatabase
  • FIG. 7 illustrates an exemplary implementation of a database control block (DBCB) data structure
  • Figure 8 illustrates an exemplary implementation of a transaction control block (“TCB”) data structure
  • Figure 9 illustrates an exemplary implementation of subdatabases into a hierarchy
  • Figure 10 illustrates an example using an active transactions field in a database control block, and context database and subdatabases fields in transaction control blocks;
  • Figure 11 illustrates an alternative implementation in which there is one search table per subdatabase, and the search table includes references to subdatabase lock control blocks;
  • Figure 12 illustrates an exemplary implementation in which the subdatabase lock control blocks are contained within an array or table
  • Figure 13 illustrates that it is possible to implement database control blocks and transaction control blocks into a single hierarchical data structure arrangement
  • Figure 14 illustrates an alternative implementation of the lock control block data structure
  • Figure 15 is a flowchart for creating a new subdatabase
  • Figure 16 is a flowchart indicating how to populate a subdatabase although physical movement of user data is not required
  • Figure 17 is a flowchart illustrating an alternative embodiment for populating a subdatabase using the data structure of Figure 11;
  • Figure 18 is a flowchart showing the handling of a lock request in the presence of nested databases
  • Figure 19 is an alternative implementation of a flowchart for handling a lock request in the presence of nested databases when the lock control block has the alternative structure of Figure 11;
  • Figure 20 is a flowchart of the process used to terminate the utilization of a subdatabase
  • Figures 21 A-21D illustrate an example in which a plurality of users desire to utilize a single database which includes four word processing documents which become organized into subdatabases;
  • Figures 22A-22D respectively correspond to Figures 21A-21D and show the data structure arrangements as the example of Figures 21A-21D is carried out; and Figures 23A-23D respectively correspond to the example of Figures 21 A-21D but utilize a data structure arrangement in which there is a search table or array for each database; and
  • Figures 24A-24D illustrate and example of the sharing of sections of a document by multiple people having different read and write capabilities by utilization of nested databases.
  • DBMS database management system
  • Transaction operation and management are handled by a transaction manager 102 and a lock manager 104, both of which are software procedures executed by the system's data processor(s) or CPU 106.
  • the transaction manager maintains a transaction table 108, sometimes implemented as a tree structure, for keeping track of the identity and status of pending transactions.
  • the lock manager 104 maintains a lock table 110, usually implemented using a hash table and various linked lists and/or tree structures (which will be discussed in more detail below).
  • the lock table 110 keeps track of locks that have been requested on resources in a database 112.
  • the lock table 110 may store information related to a memory address of a transaction, a transaction identification, a type or mode of lock, parameters of the lock, and the database or subdatabase which is associated with the lock.
  • the database 112 stores data that is accessible to transactions executed by the DBMS 100.
  • the database 112 is not required to store persistent data, although this may be the usual case.
  • the stored data could be transient.
  • the transactions that are collaboratively working on the contents of a database could be manipulating data resources that live only for a few minutes, hours, or days, and will cease to exist when the system is taken away or shut down.
  • the DBMS 100 will typically also include additional memory resources 114, one or more system busses 116 for interconnecting the various parts of the system, and a network interface 118 or other communications interface for handling communications with client workstations 120.
  • the memory 114 may be implemented using any type of memory including but not limited to random access memory, and is preferably both readable and writeable. Moreover, the memory 114 may be utilized to store the data structures of the present invention. While Figure 1 illustrates one possible implementation of the invention, any desired hardware and software can be utilized to achieve the functionality of the invention. For example, the invention may be implemented using any type of computer, computer server, and/or personal computer and/or hardware running any desired operating system. The components, structure, and operation of such hardware are well known.
  • a hash function 150 is used to convert a resource identifier ("RID") into a hash table address in a hash table 152 which may be implemented to have fixed size.
  • the resource identifier that is hashed by function 150 may include a resource type or level indicator (e.g., indicating whether the resource to be locked is a database, table, page, tuple or other) and the starting address of the resource.
  • Each addressable slot 154, such as reference 154-1 of the hash table includes either a null value if there are no locked resources corresponding to that slot's hash table address, or a pointer to a list of lock control blocks (LCB's) 160 such as LCB 160-1, if there is at least one locked resource whose hash value corresponds to that slot's hash table address.
  • LCB's lock control blocks
  • the lock manager will allocate (i.e., generate and store) one lock control block (“LCB”) 160 for each lockable data item that is actually locked, and will allocate (i.e., generate and store) one lock request block (“LRB”) 162, such as LRB 162-1, for each lock held by a transaction.
  • LRB lock control block
  • LRB 162-1 lock request block
  • Each LCB 160 preferably includes: a lock ID 170, which will typically include a copy of the resource identifier for a locked resource; a mode indicator 171 indicating the most restrictive access mode (e.g., browse, read, parameterized read, write, parameterized write, or exclusive) of all the locks granted on the database resource represented by this LCB; an optional read parameters indicator 172, preferably in the form of a bitmap, representing the logical OR of the read parameters being used by the parameterized read locks (if any) outstanding on the locked resource; an optional write parameters indicator 173, preferably in the form of a bitmap, representing the write parameters of the parameterized write lock (if any) outstanding on the locked resource.
  • a lock ID 170 which will typically include a copy of the resource identifier for a locked resource
  • a mode indicator 171 indicating the most restrictive access mode (e.g., browse, read, parameterized read, write, parameterized write, or exclusive) of all the locks granted on the database resource represented by this LCB
  • read and write parameters indicators 172 and 173 further constitute an aspect of this invention and are described in detail in U.S. Patent No. 5,983,225 to Anfindsen, which is incorporated by reference; a granted request list pointer 174 to a list of LRB s 162 for granted resource requests for the database resource represented by this LCB; a pending request list pointer 175 to a list (also called a queue) of LRBs 162 for pending (i.e., not yet granted) resource requests represented by this LCB; a database field 177 which is a reference to a database or subdatabase to which this LCB belongs.
  • a feature of this invention is that the data may be divided into different databases, referred to herein as subdatabases, virtual databases, or as databases. By making such a division, it is possible to have multiple people or transactions using the same data. In such a system, the present inventor has determined that it is desirable to know to which database a lock belongs, and such information can be readily determined using the database 177 field. While this feature of the invention is implemented using a reference such as the database reference 177, other implementations are possible such as including the database name in the LCB.
  • the database reference 177 refers to a Global Database 192. This Global Database 192 is the highest level database, and further subdatabases are referred to as DB1, DB2 ... DBn.
  • next level LCB reference 178 which indicates a subdatabase (a virtual or subdatabase at a different hierarchical level) lock control block, such as the subdatabase lock control block ("SLCB") 164-1.
  • This reference refers to either null, or a subdatabase lock control block at a different hierarchical level. Further information about this field is set forth below; and a next LCB pointer 176 to the next LCB (if any) sharing the same hash address as this LCB.
  • the read and write parameters represented by fields 172 and 173 in LCB 160 are not essential to the present invention but represent a feature which may used together with, or separate from the subdatabase aspect of the present invention. Moreover, parameters 172 and 173 represent an extension by the present invention to the conventional access modes used by DBMSs. Each distinct value of a defined set of read/write parameter domain represents a corresponding data reliability classification or category. Thus a parameter domain having eight parameter values (each represented by a corresponding bit of an eight-bit parameter field) would allow for the definition of up to eight different data reliability classifications.
  • the parameters may be used to indicate properties of a database object other than "reliability," such as the type or identity of the application which holds a write lock on the object, or other information that can be used by applications to determine if they are willing to read the data despite the presence of a write lock on it.
  • Each LRB 162, representing one granted or pending lock request preferably includes: a mode indicator 181, indicating the access mode (e.g., browse, read, parameterized read, write, parameterized write, or exclusive) in which the resource is being accessed or being requested by a particular transaction; a transaction identifier 184, which identifies the transaction that requested or holds the lock corresponding to this LRB; an optional parameters indicator 182, preferably in the form of a bit map, representing the read or write access mode parameters (if any) being used by the owner of this read or write lock; this field is used only if the owner of this lock or lock requested is using a parameterized access request.
  • a mode indicator 181 indicating the access mode (e.g., browse, read, parameterized read, write, parameterized write, or exclusive) in which the resource is being accessed or being requested by a particular transaction
  • a transaction identifier 184 which identifies the transaction that requested or holds the lock corresponding to this LRB
  • an optional parameters indicator 182 preferably in the form
  • the parameters field 182 is not essential or necessary to implement the nested databases or subdatabase aspect of the invention; a lockset pointer 185 that is used to form a linked list of the LRB's owned by transaction, such as transaction TI, identified by the transaction ID 184.
  • the linked list of LRBs may be implemented to include further features such as being doubly linked lists to allow for tracing a chain of LRBs in two directions. Further alternatives of the LRBs are described below; and a Next LRB pointer 186 to the next LRB (if any) for the same database resource as this LRB.
  • the subdatabase LCB (“SLCB”) 164-1 may be constructed in the same or similar fashion as the LCB 160-1. Thus, the subdatabase LCB 164 will be referred to as an SLCB in order to clearly indicated that the LCB is used to control the locking of access to data of a subdatabase.
  • the reference or pointer from SLCB 164-1 to the subdatabase DB1 is the database reference 177, indicating that the SLCB 164-1 is associated with subdatabase DB1.
  • database reference 177 of LCB 160-1 refers to the Global Database 192.
  • the DBMS could be set up to have all LCBs, or at least the LCBs at the first level, reference the Global Database 192, it may be possible or preferable to eliminate the database reference field 177 from the LCBs.
  • the SLCB 164-1 references LRB 162-2 which may be implemented to have the same structure as the LRB 162-1.
  • Figure 2 also illustrates two transaction control blocks TI and T2.
  • the transaction TI is associated with the Global Database whereas the transaction T2 is associated with subdatabase DB1.
  • transaction TI has a granted block request by referring to the LRB 162-1.
  • the transaction T2 references LRB 162-2, indicating the transaction T2 has a lock on the data associated with subdatabase DB1.
  • LCB Lock Control Block
  • LCB identifies a lockable resource, e.g., an object, a row (also known as a tuple) in a relational a table, or a record.
  • a lockable resource e.g., an object, a row (also known as a tuple) in a relational a table, or a record.
  • Such resources are typically identified by an object ID (“OID”), tuple ID (“TID”), or a row/record ID (“RID”).
  • OID object ID
  • TID tuple ID
  • RID row/record ID
  • a hash table is illustrated but the present invention is not limited to hash table implementations.
  • the point of consideration is that it is desirable to use a RID to find the corresponding LCB, and a hash table is the preferred implementation.
  • an array or other search-type structure may be implemented and the present invention is not limited to the use of hash tables.
  • LCBs that are reachable from the hash table merely represent a subset of all the lockable resources such as those that happen to be locked by at least one transaction at this point in time.
  • a doubly linked list can be implemented so that it is possible to trace a chain of LCBs in both directions.
  • For each lockable resource it is possible that there is a plurality of transactions holding a lock (or the lock) on the resource in question.
  • Each granted or pending lock request is represented by a Lock Request Block ("LRB"). It is preferable for each LRB to refer back or reference its LCB. This feature may be not be included in the drawings for the interest of clarity and space. It is also possible for the LRB chains to be implemented using a doubly linked structure so that it is possible to trace the chain of LRBs in either direction.
  • the first LRB to reference the last LRB in a chain of LRBs. This increases performance whenever one needs to locate the end of a chain as fast as possible (e.g., when a new LRB should be inserted at the end of the pending list).
  • the LRB 162-5 would reference the LRB 162-7.
  • FIG. 3 is an example set of data structures which may be utilized with the invention.
  • the transaction control blocks (“TCBs") TI and T2 represent transactions.
  • a transaction can have many locks, and therefore many LRBs, while an LRB preferably belongs to only one transaction.
  • TCB transaction control blocks
  • a set of LRBs is maintained.
  • the dashed or broken line is utilized to represent the relationship between the LRBs, and from the TCBs to the LRBs.
  • the LRBs may be constructed in a double linked list and further, the LRBs may be implemented such that each LRBs refers to its transaction control block.
  • each of the LRBs 162 of Figure 3 would refer to one of the TCBs TI or T2.
  • an LCB is utilized to represent both a lockable resource and a database.
  • an LCB now represents a lockable resource within a particular database (the Global Database or one of the subdatabases within it).
  • FIG 4 illustrates the data structures utilized for locking and is presented to show that each LCB (or SLCB) preferably relates to a single database, and therefore refers to a single database control block ("DBCB").
  • DBCB database control block
  • SLCB 164-1 references DB1
  • SLCB 164-2 references DB2
  • SLCB 164-3 references DB1
  • SLCB 164-4 references DB2.
  • FIG 4 it is further shown how an arbitrary number of levels of subdatabases can be created.
  • the SLCBs it is possible to implement the SLCBs to have the same structure as the LCBs and such labeling has been done in this patent application merely to distinguish the LCBs for the subdatabases from the LCBs of the Global Database.
  • some memory can be saved by implementing the SLCBs without the "next LCB reference" used to chain together LCBs.
  • the SLCBs may be linked to one another in a single direction or doubly linked as desired.
  • LCBs 160-1 and 160-2 are first level LCBs and are associated with the Global Database.
  • SLCBs 164-1 and 164-3 are second level LCBs, or may be considered first level SLCBs.
  • the SLCBs 164-2 and 164-4 are third level LCBs, or second level SLCBs.
  • the optional link between the SLCBs at the same level is represented using a dashed or broken arrow or reference, and it is also possible for double linking to be implemented so that SLCB 164-3 could also reference SLCB 164-1.
  • FIG 5 illustrates that each transaction, in the preferred embodiment, belongs to a single database.
  • the transaction control blocks TI, T2, T3, ..., Tm each reference a single database control block.
  • FIG 6 illustrates exemplary data structures in which the preferred embodiment has transactions which only access resources within their own database.
  • transaction TI which references the Global Database 192 using the solid arrow
  • transaction TI also references, using arrows constructed with broken lines, LRBs 162-1 and 162-3 which are each associated with the first level or LCB level referenced by the Hash Table 152.
  • transaction T2 and its transaction control block reference or is part of subdatabase DB1, and further references, using the arrows constructed with broken lines, LRB 162-2 and 162-4 which are associated with the second LCB level or the first SLCB level and which correspond to DB1.
  • a transaction executes within the context of one and only one database.
  • a transaction is prohibited from accessing resources not within the scope of that transactipn's database.
  • this causes the LRBs of a transaction to belong to or be associated with LCBs (or SLCBs) that reference the same database control block as that transaction's transaction control block references.
  • T2 executes within DB1. Therefore, the LRBs of T2 (162-2 and 162-4) belong to the LCBs (SLCBs 164-1 and 164-2) that reference the same database, DB1.
  • FIG. 7 illustrates an exemplary implementation of the database control block ("DBCB").
  • DBCB database control block
  • the DBCB 202 includes an identifier field 204 which is abbreviated as ID. This field indicates the name or identification of the DBCB.
  • An Active Transactions field 206 abbreviated Act Tx, enables one to trace from a DBCB to each transaction that is active at this point in time within the database or subdatabase in question.
  • the system should determine what are the active transactions of the subdatabase and if the list of active transactions is not empty, the owner of the subdatabase should get a warning indicating that there are others working within the subdatabase and questioning whether it is desirable to terminate their transactions at this point in time. It is desirable to give the entity responsible for terminating the subdatabase the possibility of changing the decision to terminate. Alternatively, the system could be implemented so that it is not permissible to terminate a subdatabase at a point in time when there are active transactions running inside of it. In this case, the transactions must be gone so that only when there are no active transactions will it be permitted to terminate the subdatabase.
  • the Active Transactions field 206 may contain a plurality of references, a single reference which is part of a linked list containing a list of all active transactions, or may contain the name or other identification of the active transactions. Additionally or alternatively, the Active Transactions field may be implemented using a doubly linked list which references each of the active transactions for the database or subdatabase at issue.
  • the owning transaction field 208 is a reference to the transaction that created and therefore owns the DBCB in question.
  • this field may be set to be a null reference and for the subdatabases, this field will reference its creator/owner transaction control block.
  • a Super Database field 210 is a reference to the DBCB that represents the database of which this database is a part.
  • a Subdatabases field 212 is a reference to the set of DBCBs that represent the subdatabases of this database.
  • a next database field 214 references the next DBCB within the same level in the database hierarchy.
  • a Previous Database field 216 is a reference to the previous DBCB within the same level in the subdatabase hierarchy.
  • the Next DB and the Prev DB fields are used to create a doubly linked list of DBCBs within a given level in the sub-database hierarchy. Thus, the subdatabases that have the same parent database may be linked together in such a list.
  • the three dots or ellipses of the last field of the DBCB 202 represent that additional fields may be contained in the DBCB, as desired.
  • the purpose of the DBCB is to specifically and accurately indicate where in the resource hierarchy or the database hierarchy a specific thing such as a lock belongs. Thus, one is able to readily determine the relationships of the subdatabase to the rest of the system.
  • DBCB transaction control block
  • TBCB transaction control block
  • the DBCBs preferably form a hierarchy. However, alternative implementations are possible which do not have the DBCBs arranged in a hierarch.
  • FIG. 8 illustrates a Transaction Control Block (“TCB”) data structure 222.
  • TBC Transaction Control Block
  • This data structure is utilized in order to indicate the active transactions, indicate to what database or subdatabase level the transaction belongs, and/or to determine the locked resource and status of the locks of a transaction.
  • Identifier field 224 which identifies, for example, the name of a transaction.
  • a Context Database field 226, abbreviated Ctxt DB, is used to reference the DBCB of the database that represents the scope or context for the transaction in question. This may be determined at the time of transaction creation. In accordance with an embodiment of the invention, from the time a transaction is born until it is terminated, it lives its life and performs all its actions within a single database. The present invention operates efficiently and properly by utilizing, in the preferred embodiment, a rule which makes a transaction exist from the beginning to the end of its lifetime in a single context.
  • the context database field 226 may be utilized to represent the scope or content of the transaction in question.
  • the context database field 226 may reference the Global Database, meaning the transaction corresponding to the TCB executes within the Global Database or has the Global Database as its context database.
  • the Subdatabases field 228 of Figure 8 is utilized to represent a set of subdatabases that this transaction has created. Note that it is possible for this field to be empty or to reference null. A transaction can create and therefore own a number of subdatabases. Depending on what action is being performed, it may be desirable to determine how many subdatabases exist for a specific transaction. Therefore, when it becomes desirable to terminate a transaction, it is preferable to know what subdatabases exist before such a termination is performed. Similarly, it is desirable to know the subdatabases for the database control block, as explained above.
  • Field 230 represents the Granted Lock Requests of the TCB and field 234 represents the Pending Lock Requests of the TCB. These fields 230 and 234 may be implemented using references from TCBs to the LRBs, as illustrated in the figures, for example in Figure 6.
  • the Super Transaction field 236 may be utilized, if desired, to maintain a hierarchy of transactions or TCBs.
  • the super transaction field 236 will reference or point to a transaction which is higher in the hierarchy than the transaction at issue.
  • the transaction field 236 may be utilized to reference the transaction which has created or allowed the creation of the transaction at issue.
  • Figure 9 illustrates the relationships between the DBCBs, and also the relationship between the DCBCs and the TCBs. These data structures are utilized to control the locking of resources.
  • the hash table, LCBs, SLCBs, and LRBs are not illustrated so that the diagram does not become overly complicated. However, these data structures are ordinarily present in the system.
  • TCBs TI, T2, T3, ..., Tm there are also illustrated DBCBs 240, 250, 260, 270, 280, 290, and 300. In this example, the hierarchy of the DBCBs can be observed.
  • the DBCB 240 is the highest DBCB in the hierarchical DBCB structure, and may correspond to the Global Database 192.
  • the ID field 241 would indicate that this DBCB is for the Global Database.
  • the Own Tx field 243 points to null, as it is not necessary to expressly identify in the DBCB the owner or owning transaction of the Global Database.
  • the Sup DB field 244 also points to null, as there is no super database for the Global Database.
  • a Sub DB field 245 references the set of subdatabases for this database, and in this case references DBCB 250.
  • DBCB 250 At the Global Database level in this particular example, there are no other databases at the Global Database level, and therefore, the Next DB field 246 and the Prev DB field 247 each point to null.
  • the Active Transactions field 206 shown in Figure 7 has not been illustrated simply to simplify the diagram but in a preferred embodiment, the Active Transactions field would be utilized, as explained above.
  • DBCB 250 At the hierarchical level below the DBCB 240 are the DBCBs 250 and 260. Not every field in Figure 9 will be explained as these fields are self-explanatory. However, with regard to DBCB 250, it is seen that the Owning Transaction 253 references T2, that the Super Database 254 for this DBCB is the Global Database, as represented by DBCB 240. The subdatabases for this DBCB 250 are indicated by the reference Sub DB 255 which references DBCB 270. The other subdatabases 280,290, and 300 of the database 250 are linked to the subdatabase 270. The Next DB field 256 references DBCB 260, and the Prev DB field 257 references null.
  • DBCB 260 which is at the same hierarchical level as DBCB 250, the Owning Transaction 263 is T3, the Super Database 264 references DBCB 240, there is no subdatabase for the DBCB 260, as represented by the Sub DB field 265 referencing null, and there is no Next DB, as indicated by the field 266.
  • the Prev DB field 267 references DBCB 250.
  • the Super Database field will generally reference one super database except for the Global Database which will not reference any super database. Such referencing is what allows the hierarchy to be represented.
  • the illustration of Figure 9 is merely an example of how the DBCBs may be arranged during a specific series of transactions, and the exact hierarchy in Figure 9 is not required.
  • transactions T2 and T3 preferably execute in the Global Database because otherwise, they probably would not have been able to create subtransactions that belong within the Global Database. Therefore, the fact that the DBCBs 250 and 260 have the Global Database, as represented by DBCB 240, as their superior database indicates that the owning transaction has the Global Database as its scope or context. Moreover, as explained above, it is preferable that for each DBCB, there is only one super database but there is any number of subdatabases. However, alternative implementations may not have such a requirement.
  • Figure 9 illustrates a doubly linked list structure, for example by having DBCB 250 reference DBCB 260, and also having DBCB 260 reference DBCB 250, such a doubly linked list relationship between the DBCBs is not an essential requirement, but other implementations such as tree structure implementations may be utilized. For example, there could be a pointer or reference from a DBCB which points to or references a separate object whose purpose is to represent a set or list of some structure which indicates the location of the DBCBs. This alternative implementation would add another data structure to the data structure arrangement. Such an alternative arrangement might add more complexity into the data structure arrangement, but there may be advantages to doing so. One such example would be allowing one to eliminate, if desired, the next and/or previous references of the DBCBs.
  • Figure 10 illustrates additional details of the TCBs and the DBCBs which are not shown in Figure 9. This detail was omitted from Figure 9 for purposes of clarity and to prevent the drawing from becoming too cluttered. Similarly, features of the DBCBs which are contained in Figure 9 have been omitted from Figure 10 for purposes of clarity.
  • the Active Transaction field has been illustrated in the DBCBs, and the use of the Context Database and Sub-Database fields has been illustrated with respect to the TCBs. These fields in Figure 10 show in a more detailed manner the relationship between the DBCBs and TCBs.
  • the DBCB it is preferable for the DBCB to keep track of its owning transaction, as illustrated in Figure 9, and it is also preferable to keep track of the active transactions of the subdatabase.
  • Such a function is performed by the Active Transactions reference or field of the DBCB.
  • the DBCB 310 has an identification field 311 and an Active Transaction field 312.
  • the Active Transaction field 312 references TCB 320.
  • the owner of the subdatabase corresponding to DBCB 310 can determine that the transaction corresponding to TCB 320 is an active transaction for the DBCB 310.
  • it is seen at the right-most portion of TCB 320 that there is a reference to TCB 330, and TCB 330 references TCB 340.
  • the TCB 340 references the TCB 330 which references the TCB 320.
  • the Context Database field of each of TCBs 320, 330, and 340 reference DBCB 310.
  • a transaction When a transaction is created, started, or begun, that transaction preferably has some sort of context within which it is going to execute. In a classical context and in the prior art, this setting is always the Global Database. However, with the nested databases of the present invention, a transaction can be started and execute in the Global Database, or a transaction can begin in a subdatabase. Preferably, no data outside of the subdatabase within which a transaction has been started is accessible, and preferably, the lock manager knows or can determine the database within which this transaction is executing, and this is what is referred to as the context database. If the resource which a transaction is requesting is outside of the context database, a request to access such information will preferably be denied by the lock manager.
  • the Sub DB field 323 of TCB 320 references DBCB 348
  • the Sub DB field 333 of TCB 330 references DBCB 346
  • the Sub DB field 343 of TCB 340 references DBCB 347.
  • a super database pointer or reference of these DBCBs references the DBCB 310.
  • the DBCB 348 references TCB 360 using the Active Transaction reference thereof.
  • TCBs 360 and 364 each reference DBCB 348 using their corresponding Context Database references.
  • the detailed structure of the fields of the simplified DBCBs and TCBs of Figure 10 has been omitted for clarity and to prevent Figure 10 from becoming overly cluttered with references.
  • Figure 11 illustrates an alternative implementation of the data structures utilized to control and monitor the locking of resources.
  • the lock manager when the lock manager processes a lock request for a lock on a certain resource in a certain database, it will first use the resource ID ("RID") to find the LCB for the given resource in the global database. Thereafter, if necessary, it will use the "Next Level LCB" reference to find the LCB for the same RID but in the particular database or subdatabase identified by the lock request being processed.
  • RID resource ID
  • Next Level LCB reference to find the LCB for the same RID but in the particular database or subdatabase identified by the lock request being processed.
  • the alternative embodiment of Figure 11 (and also the alternative embodiment of Figure 12) allows a reverse sequence of events as compared with what was previously described.
  • Figure 11 allow the lock manager to first locate the database, as represented by the DBCB, and subsequently locate the RID within that database. This is achieved by having one search table per DBCB rather than just a single global search table such as the previously described hash table.
  • the DBCBs in addition to referencing their owning TCB, reference a search table that provides access to the RIDs contained within the database in question.
  • DBl references table 380 DB2 references table 390
  • DBn references search table 400.
  • Each of the search tables 380, 390, and 400 have references to the SLCB which provides information relating to the lock of a particular data item.
  • LRBs can be used for granted and pending lock requests associated with SLCBs, in the same manner as they were used with respect to the embodiment described above.
  • the subdatabase search tables such as 380, 390, and 400 can be implemented as hash tables, but they can be implemented in alternative manners. For example, they could be implemented using fixed-size arrays of LCB references. Such an implementation could be beneficial if the size of the subdatabase is fixed at the time of the subdatabase creation, or alternatively can be implemented utilizing dynamic size arrays (growable arrays) of LCB references. If hash tables are used as the subdatabase search tables, these hash tables can be allocated with fewer entries, if desirable, than the Global Database hash table.
  • hash tables are used as the subdatabase search tables, it would be possible to have chains of LCBs for any given hash table, for example as shown with respect to the search table 400 having reference 402 refer to SLCB 164-5 which references SLCB 164-6.
  • the "Next Level LCB" field of the LCB or SLCB is no longer necessary.
  • each subdatabase DBCB has a reference to its owning TCB, and also each TCB has a reference to its containing DBCB.
  • the data structure of Figure 11 does not eliminate the use of super database references, even though such references are not shown in Figures 11 or 12.
  • DB2 by the reference from DB2 to T4, but T4 executes within DBl. From this information, it is possible to conclude that DB2 is a subdatabase that is contained within DBl. It should be kept in mind that Figure 11 is merely an example of a subdatabase system and could have been illustrated in other manners. However, as shown in Figure 11, whatever is inside of
  • DB2 is a subset of DBl because of the connection through T4.
  • Figure 11 also illustrates that
  • T5 and T6 execute with DB2 as their context.
  • T6 creates DBn, and T7 and T8 execute within
  • Figure 12 illustrates a further alternative implementation of the invention.
  • subdatabases can be small in size, because they may be implemented to contain a small number of lockable resources, it may be possible to implement the subdatabases as a fixed size, if desired, and the Search tables 410, 414, and 416 may be implemented, if desired, as an array of LCBs.
  • the LCBs are for subdatabases, the LCBs in Figure 12 are illustrated as
  • SLCBs ("Subdatabase Lock Control Blocks") 164-1 through 164-20.
  • the arrays of SLCBs may be utilized as opposed to an array of references or a hash table of LCB references.
  • the Hash Table 152 is preferably implemented in the same manner as described with respect to the earlier embodiments.
  • This hash table implementation for the Global Database allows a large number of LCBs to be used for the Global Database, if desired. If a specific use of the subdatabase is known, or even if it is not known, it may be appropriate to limit the number of items in a subdatabase to an arbitrary number, such as 20 data items. This number may be larger or smaller if desired.
  • the embodiment may be implemented such that the arrays 410, 414, and 416 are created to have 20 pieces of memory, each capable of holding one entire SLCB. Then if only a portion of the allocated memory is used, the unused portion is wasted but this unused portion may not be so large and the advantage of not having to deal with dynamic memory allocation whenever a new LCB is introduced may be achieved. It is also possible to have chains of LCBs such as linked lists or double linked lists without a search table and to do sequential searches of the pointer or the reference chains whenever there is a need to locate a specific LCB.
  • Figure 13 illustrates a hierarchy which contains both data structures related to the - DBCBs, and the TCBs.
  • the invention it is possible to view the transactions and databases as being the same kind of "thing.” This is possible as the database can be viewed as a passive transaction.
  • a transaction e.g., TI
  • a unified approach of the DBCBs and the TCBs in a single hierarchical data structure is possible.
  • ATCB active TCB
  • PTCB passive TCB
  • ATCB active TCB
  • PTCB passive TCB
  • the root of the hierarchy which may be referred to a as a database/transaction hierarchy, is the Global Database PTCB 420.
  • This node corresponds to the Global Database data structure 192 described above.
  • the starting point of the hierarchy is the Global Database which is the root of the hierarchy, and from then on, the database/transaction hierarchy can dynamically develop (grow and shrink) in almost any conceivable way as transactions and subdatabases are created and terminated.
  • the PTCB for a Global Database will be present as long as the system exists for which the transaction management and lock management is being done, while all other nodes may be transient.
  • the PTCB for the Global Database may be implemented such that it is permanently present.
  • the unified structure of Figure 13 can be used with any of the implementations described above. This means that the system can be implemented either to have a global search table that provides access to all LCBs, or can be implemented to have a search table per PTCB which gives access to those LCBs that belong to the PTCB in question.
  • the Global Database PTCB 420 is seen to be at the highest hierarchical level. Immediately below the Global Database PTCB 420 are four transactions ATCB 422, ATCB 424, and ATCB 426. These three ATCBs are top level transactions which have the Global Database PTCB as their immediate parent node. All other transactions and ATCBs in the hierarchy of Figure 13 may be considered subtransactions.
  • a reason why it is possible to implement the data structure relationship illustrated in Figure 13 is that the inventor has determined that a subdatabase can be regarded as a passive transaction, and as a subdatabase will always be created by an active transaction, the subdatabase is going to be a subtransaction.
  • An advantage of the hierarchy and unification of data structures illustrated in Figure 13 is that there is provided a potential simplification as compared to the arrangement illustrated in Figure 10.
  • This simplification may result because rather than having pointers or references that cross back and forth between the two different hierarchies of TCBs and DBCBs, there is a single hierarchy.
  • the system may be implemented to only include the supernode. For example, looking at Figure 10 where the transaction control blocks have a pointer or reference to the context database, the data structure in those previous implementations is preferably implemented, though not required, with another pointer or reference to a super transaction.
  • Such a super transaction and context database references or pointers may be combined into a single reference.
  • the search table such as a hash table, the LCBs, the SLCBs, and the LRBs are used in this embodiment in a similar manner they are used in the preciously described embodiments.
  • the Context Database field 226 of Figure 8 could be combined with the Super Transaction or parent transaction field of the TCB of Figure 8.
  • the ATCB in a very similar manner as the TCB, although additional changes may be made, if desired.
  • each of the previous embodiments preferably used an LCB or SLCB which referenced a lock request block or LRB.
  • LRB lock request block
  • the alternate implementation of the LCB or SLCB is illustrated as the data structure 460.
  • This data structure integrates the information stored by the LRBs into the LCBs so that the LCBs (and SLCBs) are richer control blocks containing more information than the classical style LCBs (and SLCBs).
  • the data structure of Figure 14 is based upon and similar to the data structure of Figure 3 illustrated in U.S. Patent No. 5,983,225 which is incorporated herein by reference.
  • the data structure 460 includes a lock ID field 462 which will typically include a copy of the resource identifier for a locked resource or some other identification of the resource at issue.
  • a mode field 464 indicates the most restrictive access mode of all the locks granted on the database resource represented by this LCB.
  • a granted request bit map field 466 and a pending request bit map field 468 each contain a bit map of sufficient size (e.g., 64 or 128 bits) to represent a maximum number of concurrent transactions supported by the system (or sub-database level). Each transaction is assigned to one of the bit map transaction identifiers.
  • the granted request bit map 466 contains a set bit for each active transaction that has been granted a lock resource represented by the LCB (or SLCB) 460.
  • the pending request bit map 468 contains a set bit for each active transaction that has a pending lock request (also called and access request) on the resource represented by the LCB 460.
  • a database field 470 contains a reference to the DBCB representing the database for the resource corresponding to the LCB 460.
  • a transaction when a transaction is accessing the resource at issue, it preferably indicates which database it is accessing the resource in, and there will be one LCB (or SLCB) for each database within which the resource at issue belongs, and the LCB (or SLCB) preferably should be able to identify explicitly that a database at issue corresponds thereto. This is the purpose of the database field 470.
  • Field 474 represents that additional fields can be contained in LCB/SLCB 460.
  • read and write parameter bit maps as illustrated as elements 172 and 173 of Figure 2 of U.S. Patent No. 5,983,225 may be utilized in order to represent read and write parameterized access modes that have been granted on the database resource represented by the LCB 460.
  • other fields may be included in the area 474 of the LCB 460.
  • a Next LCB field 476 may be utilized to represent the next LCB and may correspond to field 176 of Figure 2.
  • the database field 470 and the Next level LCB 472 may be implemented in a similar manner as the database field 477 and the Next Level LCB field 178 are implemented with respect to Figure 2.
  • the alternative implementation of the LCB or SLCB 460 can be substituted into any of the earlier figures in which an LCB or SLCB is used, and this would allow the possibility of eliminating the LRBs which are preferably used with those embodiments.
  • the present invention relates to transactions and a transaction may be considered a logical unit of work. Such a transaction may be based on a human sitting at a terminal doing work, or it could be something based on a running or a submission of an already existing computer program and a request for the system to execute the instructions of that program.
  • a subtransaction relates to the idea of working with, under, or in association with a transaction. The dividing of a transaction into sub-units may be considered as the creation of subtransactions. If desired, and only as an example implementation, a transaction may be considered to be independent of other transactions and can be an autonomous unit of work. On the other hand, a subtransaction may be considered a non-autonomous or non-independent transaction. Thus, subtransactions can be considered a part of transactions at a higher level.
  • a database can be thought of as a collection of data.
  • a subdatabase is also a collection of data, but a subdatabase is generally dynamically created and may be considered to be a transient entity.
  • the subdatabase may be implemented so that it lives only as long as the creating transaction lives and when the entity which created a sub-database ceases to exist, the subdatabase will also cease to exist.
  • the subdatabase can be considered as being, or being related to, a sphere of control which puts a fence or line around a subset of the data and what is inside of the fence is regarded as the subdatabase.
  • the subdatabases are also considered to be virtual databases. In this writing, the term database may be used to refer to subdatabases or virtual databases.
  • the subdatabase may be considered virtual in the sense that it does not have to be materialized. It is not necessary to have a separate physical copy of the data in the subdatabase in accordance with an implementation of the invention. Thus, it is possible to have a single copy of the data which belongs to the Global Database, and simultaneously can belong to one or more subdatabases which corresponds to the Global Database Control Block 192, without the need to create separate physical copies of the data.
  • the data is preferably stored in the Global Database, such as the database illustrated in Figure 1.
  • the Global Database 192 is preferably implemented as a database control block which is utilized during the process of managing and operating the lock manager of the DBMS.
  • the Global Database 192 and the other DBCBs DBl, DB2, ..., DBn are not directly used as an entry point to obtain the desired data, and the data is preferably not stored in these data structures.
  • RID record ID
  • the hash table is utilized in order to get the entry for that RID which when found will point to a possibly empty chain of LCBs or an LCB that corresponds to the particular RID. LCBs which belong to other RIDs may be ignored.
  • the LRBs corresponding to the LCB which was found through the hash table are examined to see if there are any conflicting locks and if the lock request can be granted. If so, the LRB corresponding to the requested lock will be introduced into the chain of granted LRBs and permission to access the data will be granted. At this time, it is possible to go to another component of the system which is well known and not illustrated and may be referred to as a buffer manager or other item which allows access to the disk and the physical address of interest to fetch the record in order to obtain the actual data. If nested databases or subdatabases exist, database control blocks are utilized to obtain permission to access the data.
  • the database control blocks are preferably not used to directly access data.
  • the hash table is utilized to find the corresponding LCBs that hangs off of that hash table, as described above.
  • the entry for the RID in question is obtained and there is a move to the right in the drawings to find the LCB for the RID in question.
  • Figure 4 there are the first level LCBs 160-1 through 160-2. From the hash table 152 of Figure 4, the reference 154-1 is found which leads to the LCB 160-1.
  • LCB 160-1 refers to the Global Database DBCB 192.
  • database 2 e.g., DB2
  • the transaction in question is executing in the context of database 2, and therefore, it is necessary to find the SLCB for the correct resource. It is necessary to move from the first level LCB 160-1 to the second level LCB 164-1.
  • the SLCB 164-1 references DBl which is not the database which is of interest. Therefore, continuing up the LCB/SLCB hierarchy one level to the third level of LCBs, it is seen that the SLCB 164-2 refers to DB2 and as we are interested in DB2, the correct level of LCBs has been reached.
  • the lock manager now examines what locks are present for this database and this resource at the SLCB 164-2.
  • the database control block is preferably used for concurrency control and is used by the lock manager, but it is preferably not used by the buffer manager or some other mechanism in the system that goes out to fetch the data.
  • the database control blocks in a preferred embodiment, are just control blocks and do not contain the data; they contain control information. So, once the lock has been granted, the system provides an indication that a certain transaction is entitled to a particular RID.
  • the buffer manager preferably does not need or utilize the DBCBs to get the data. Obtaining the data is a matter of physical access paths, and where on the disk the desired data is going to reside.
  • the record or object of whatever is desired preferably exists as one copy. It has a physical address on the disk and the buffer manager is capable of figuring out the physical address given the RID, and it does not matter to the buffer manager which subdatabase the data belongs to; the physical address is preferably the same in any case.
  • the SLCBs and LCBs have been illustrated as including a reference or pointer to the DBCBs. It should be noted that an alternative embodiment may eliminate this reference or pointer by including a field within the LCB or SLCB which is a number or identification which indicates that the SLCB belongs to a particular database or subdatabase. Alternative implementations of the reference to the LCB or SLCB are possible.
  • the data structures used to implement the subdatabases of the present invention introduce recursion into the well-known concurrency control technique known as locking.
  • Recursion has to do with applying a given principle over and over again and in this particular context, starting out with a Global Database which stores a global collection of data items, for instance word processing or engineering or CAD/CAM design documents or structures.
  • the concurrency control is performed by means of locking to make sure that one person or transaction does not corrupt or make improper the data which another is working on.
  • a principle is to create nested databases or subdatabases which may be thought of as mini-databases, and then to perform the same basic concept and locking for the subdatabases that is done for Global Databases.
  • the present invention applies the principles in the Global Database to the virtual collection of subdatabases.
  • the present invention applies the principles of recursive concurrency controls to the problem of collaboration, and this enables the creation of virtual databases or virtual sandbox environments.
  • the invention allows the use of ordinary concurrency controls, and the establishment of arbitrarily complicated patterns of interactions between two or more users who desire to collaborate. If there is a desire to cancel a modification of the data or have recoverability to a previous state of the data which relates to the property of atomicity, the invention may be implemented to maintain a log of everything that is done with each data item under the scope of a transaction. The contents of that log enable both forward and backward recovery of any item which has been modified.
  • a write lock permits one to write, delete, insert, and modify data, and according to the preferred embodiment, is a prerequisite for the creation of a subdatabase.
  • the subdatabase may be considered to create a database lock, as opposed to a write lock.
  • the lock manager with regard to a particular transaction causes the transaction to live its life inside the scope of a certain database. Therefore, the present invention may be implemented to use a recursive algorithm that recognizes transactions having different scopes or subdatabases.
  • the invention is different from the parameterized lock management system described in U.S. Patent No. 5,983,225, although the present invention may be implemented along with the techniques of U.S. Patent No. 5,983,225 in order to make the system more powerful and have additional features.
  • the nesting or the nested databases and the use of the subdatabases in the present invention has a purpose of coordinating multiple writers of data.
  • FIG 15 there is illustrated a flowchart for creating a new and empty subdatabase.
  • An implicit context of Figure 15 is that there is a transaction executing in the database or some other subdatabase within the Global Database and the owner or person who is in control of this transaction desires to create a new database.
  • step 482 creates a new DBCB.
  • the database confrol block is created in order to have a point of confrol or point of reference for the existence of this new subdatabase that is about to be created.
  • Steps 484, 486, and 488 relate the created DBCB to the other data structures which may exist.
  • step 484 the Own TX field of the DBCB is made to reference the creating or owning transaction. This step is performed in order to make explicit the relationship between the creating transaction and the new DBCB. It is to be noted that all steps of each flowchart are not essential and depending upon the implementation used, certain steps may be omitted if desired, or if the named data structures or fields are not used.
  • step 486 makes the Super Database field of the DBCB reference the appropriate super database of the DBCB. This is performed in order to indicate to the system or make explicit in the DBCB data structure what is the database of which this new subdatabase is a part.
  • Step 488 then writes the Next DB and Prev DB fields in the DBCB data structure so that they reference sibling databases, if any. These sibling databases may be other subdatabases previously created by the same creating transaction, if any, such that relationships with the other subdatabases may be defined or created.
  • step 490 is performed which writes in the creating transaction's TCB the appropriate information such that this DBCB is referenced by the Sub DB field of the creating transaction's TCB.
  • This step ensures that the super database includes this new database in its set of subdatabases that it has within itself.
  • step 492 a new search table for the LCBs is allocated and this new search table is referenced from this DBCB.
  • this step 492 does not have to be performed for all embodiments, but may be desired for the data structures of Figure 11 and/or the data structures of Figure 12.
  • each DBCB preferably has its own Hash table, array, or other search structure which is used as an entry point for locating RIDs which are within its domain or subdatabase. The process of Figure 15 then ends.
  • Figure 16 illustrates a process of bringing the RID into a subdatabase in order to populate the subdatabase.
  • the subdatabase which has been created in Figure 15 will be empty upon initial creation and Figure 16 illustrates how an object or data item can be pulled into the subdatabase so that the object or data item can be made available to future transactions that are going to execute in the subdatabase at issue.
  • step 500 determines if the operation at issue is valid. This step is performed because in the preferred embodiment, one cannot move any object into a subdatabase but certain conditions should exist. As an example, the transaction that created and therefore owns the subdatabase is preferred, at this point in time, to be in possession of the object that it wishes to bring into the subdatabase.
  • step 500 determines that the operation is valid, flow proceeds to step 502 so that the object at issue can be brought into the subdatabase.
  • the embodiment of Figure 16 relates to the data structure arrangement such as that which is illustrated in Figures 2-4 and 6.
  • step 502 locates the LCB for this RID in the super database. This step is preferably performed by going to the hash table, hashing the RID, getting a hash table entry or reference, and then following the pointer chain or reference from the hash table to the LCB at the first level. That LCB is going to identify the RID in the Global Database.
  • this subdatabase into which the object at issue is now being pulled is not an immediate descendent of the Global Database but has some other subdatabases above it that is between the Global Database and itself, then it is appropriate to traverse the next level database references or next level LCB from one LCB to the other until the LCB that identifies the resources in the immediate Super Database of this subdatabase is reached. And because of the tests performed with respect to step 500, it is known that there is going to exist such an LCB.
  • step 504 is performed which allocates a new LCB for the RID at issue in this database or subdatabase.
  • This new LCB is going to represent the very same resource in this new subdatabase that we have created and into which the resource is being brought.
  • step 506 the LCB for this RID in the super database is made to reference the new LCB.
  • step 508 makes the new LCB reference the DBCB for this database. In other words, it is desirable to make sure that the new LCB explicitly represents its connection to a database by indicating that this is my database or my context database. The process of Figure 16 then ends.
  • Figure 17 is a flowchart showing how to populate a database or subdatabbase but is used with the alternative implementation having the data structures which are illustrated, for example, in Figure 11 and 12.
  • a principal purpose of such populating is to implement a locking structure by creating an LCB in order to determine the lock status of a resource.
  • step 510 is performed which determines if the operation at issue is valid. This step is the same step as step 500 of Figure 16, and therefore a repition of the explanation of this step is omitted.
  • step 512 the DBCB for this database is located. At this time, the database such as the global database or some subdatabase which is of concern is known.
  • step 514 there is an allocation of a new LCB (or SLCB) for the RID at issue in this database.
  • a new LCB is being created as a new object is being brought into the database.
  • the LCB is inserted into the search table of the database.
  • FIG 18 is a flowchart showing exemplary steps of lock request processing utilizing the data structures of the embodiment of the invention illustrated with respect to Figures 2-4 and 6.
  • step 520 is performed which locates the hash table slot for the RID at issue.
  • a lock request will identify the transaction that is asking for access to a piece of data, and it will identify the RID or the record ID of the data in question along with the database in which this RID is to be found. Moreover, there will be an indication of the access mode such as whether the data is desired to be read or written. This information is available to the lock manager when processing the lock request.
  • step 522 determines that the LCB for the RID does not exist in the global database, flow proceeds to step 530 which creates an LCB and inserts it into the first level LCB chain.
  • step 530 step 532 grants the request and creates an LRB which corresponds to the granted request.
  • step 524 is performed which follows the "Next Level LCB" until the correct database or subdatabase is found. Note that it is possible that step 524 can be executed zero times, so even if there is a request for a resource in the global database, it may be immediately discovered that the LCB which is being viewed is the desired or correct LCB, and therefore, it is possible to stop with this LCB and not proceed any further.
  • step 526 is performed which determines if there are any conflicting locks which exist. This is readily determined by examining whether the request is compatible with any existing locks which might already have been granted on the data item.
  • step 526 determines that there are conflicting locks
  • flow proceeds to step 528 in which the request is queued or rejected. It is possible to implement the system so that there can be a waiting period, hoping the existing locks will be released so that the lock manager can reconsider at some later point in time whether it is now possible to grant the requested lock. Alternatively in step 528, the requested lock can simply be rejected; it is a matter of design choice as to how this issue is handled. An immediate rejection of the request prevents a hanging or waiting of an arbitrary amount of time in hope of getting access to the lock which is desired.
  • step 526 If there are no conflicting locks which are determined to exist in step 526, flow proceeds to step 532 which grants the request and creates an LRB relating to the request in order to properly indicate the locking of the resource or associated data.
  • Figure 19 like Figure 18, also illustrates how a lock request is handled in the presence of nested databases, but relates to the data structures of Figures 11 and 12 in which every database or subdatabase control block has its own search table.
  • the LCB search table for the database in question is located. This may be performed by following the search table reference from the DBCB of the database identified by the lock request.
  • the hash table slot for the RID is located, if such data structures exist for the embodiment.
  • this embodiment may be implemented to have a more direct representation or allocation of LCBs.
  • step 538 is performed which determines if the LCB for the RID already exists.
  • step 537 it is determined whether the request is for a resource in the global database. If so, flow proceeds to 544. However, if the request is for a resource in some subdatabase, but the LCB for the resource is not present in that subdatabase's search table, then we have a special situation in that the transaction is asking for something outside the scope of its context database. Normally, such a request would be rejected, and this is indicated by the NO branch of step 539. However, the system could be programmed in such a way that the possibility of dynamically bring the requested resource in at this time, and thus dynamically growing the subdatabase in question, is kept open by the query of step 539 which determines whether the subdatabase should be allowed to grow.
  • step 539 flow proceeds to 544.
  • the flowchart of Figure 18 can be modified to insert between steps 522 and 530, steps 537 and 539 of Figure 19. This will allow the functionality of steps 537 and 539 to be achieved in the process of Figure 18.
  • step 538 if it is determined that an LCB for the RID already exists, flow proceeds to step 540 in which it is determined if any conflicting locks exist. If a conflicting lock does exist, the lock request is queued or rejected, as explained with respect to step 528 of Figure 18. If there are no conflicting locks, flow proceeds to step 546 in which the request for the lock is granted and an LRB is created, as explained above. The process of Figure 19 then ends.
  • FIG 20 is a flowchart illustrating the steps performed during termination of a subdatabase.
  • step 550 determines if any transactions or subdatabase of this database exists. If the answer is YES to either of the inquiries of step 550, flow proceeds to step 552 which asks whether there is a desire for this process to continue.
  • the decision block of step 552 can be performed in any desired way and can be a manual decision by the user after querying the user of the system if he or she still wants to terminate the subdatabase. Alternatively, there could be an automatic decision indicating whether or not it is acceptable to terminate the subdatabase.
  • step 552 If there is a desire to preserve the subdatabase because transactions or subtransactions of this database exist, flow proceeds from step 552 and the process ends as the data at issue is desired to be preserved.
  • the continue decision of step 552 can be a preprogrammed or computer program decision, or may be a manual decision. If there is a desire to continue with the termination in step 552, step 554 is performed in which all subdatabases and transactions of this database are terminated. This termination is another example of recursion because executing the action of step 554 will cause the flowchart of Figure 20 to be re-executed for the items being terminated in step 554.
  • step 556 is performed which deallocates all of the LCBs for the database at issue. This deallocation of step 556 can be safely performed as there will be no LRBs and no transactions or subdatabases depending on these LCBs so it is possible to take them away or deallocate them (e.g., removing them from the computer's memory).
  • step 558 is performed which deallocates the search table, if it is used. It is to be noted that in some instances, there may not be a search table to be deallocated, and therefore, step 558 does not need to be performed.
  • step 560 is performed which deallocates the DBCB for the database at issue, and once step 560 is performed, there will ordinarily be no more data structures in the computer memory dedicated to this subdatabase and the subdatabase now ceases to exist. The process of Figure 20 then ends.
  • Figures 21A-21D an example of what the invention can do is illustrated with respect to Figures 21A-21D.
  • This example is an example of the sharing of documents, but the invention has many more applications and may be used in any situation in which there is a desire to share data among a plurality of users.
  • the present invention may be used to share portions of a document among users so that there may be simultaneous work on a single document by a plurality of users.
  • a single screen or computer display is shown for each user and each of the documents or data items available for that user are shown on the screen.
  • FIG. 21 A there is shown a computer screen 570 of Gail having four documents, document 1 572, document 2 574, document 3 576, and document 4 578.
  • this screen 570 of Figure 21 A Gail has write locked documents 1, 2, 3 and 4 and she can both read and write the contents of these documents.
  • Gail has a top-level transaction in the global database.
  • Gail has created a subdatabase and pulled, logically speaking, documents 2, 3, and 4 into this subdatabase. This has caused those documents to become read only, as designated by "R/O" in the upper right-hand corner of each document.
  • FIG 21 C a screen shot 570 for Gail is shown, and it is also shown that Brian now has the ability to work on document 2 582, and document 4 584 as indicated on his screen 580.
  • FIG 21D Gail's and Brian's screens 570 and 580 can be seen, but additionally, Anne has a screen 590 which illustrates document 2 592 which is a read only document, and document 3 594.
  • Anne has started a transaction in Gail's subdatabase. She has a read lock on document 2 and a write lock on document 3, indicating that only document 3 can be modified by Anne.
  • FIG. 22A-22D illustrate a first example of data structures which may be utilized to implement the example of Figures 21A-21D, respectively.
  • TBC Transaction Control Block
  • LLB Lock Control Block
  • LRBs Lock Request Blocks
  • LRBs Lock Request Blocks
  • Each of the LCBs 160 in Figure 22A references the Global Database 192 (actually the Global Database Control Block), thus representing that Gail has a top-level transaction in the Global Database.
  • the Global Database 192 (actually the Global Database Control Block), thus representing that Gail has a top-level transaction in the Global Database.
  • the TCB 600 which is Gail's top-level transaction, there are full edit capabilities for each of documents 1-4.
  • the LCBs for these documents, and thus the data itself, is to be considered part of or related to the global database.
  • FIG 22B which corresponds to Figure 2 IB
  • Gail creates a subdatabase and moves, logically speaking, documents 2, 3, and 4 into the subdatabase.
  • a subdatabase may be created in order for Gail to invite others to collaborate with her.
  • additional data structures are illustrated in Figure 22B.
  • second level LCBs also referred to as SLCBs
  • SLCBs are created for documents 2, 3, and 4 and are represented by the designation 164-2, 164-4, and 164-1, respectively. It is seen that each of these SLCBs reference Gail's subdatabase control block ("DBCB") 602.
  • DDCB subdatabase control block
  • Gail's TCB remains the global database 192, and Gail's subdatabase DBCB 602 references Gail's TCB 600 in order to indicate that Gail's subdatabase is owned by Gail's transaction.
  • Brian has started a transaction within Gail's subdatabase, and Brian's transaction is represented by Brian's TCB 604 at the upper right-hand portion of Figure 22C.
  • Brian's transaction in this particular example, can access only documents 2, 3 and 4 as these are the documents of Gail's subdatabase which Brian's transaction has permission to access.
  • an implementation of this invention may allow Gail to dynamically grow her database by adding more documents to it, even after another such as Brian begins a transaction within the subdatabase.
  • Brian has placed write locks on documents 2 and 4, and has full edit capabilities for those documents.
  • Gail can see what Brian is doing to the documents, but she cannot directly overwrite his changes.
  • the ability for Brian to have a write lock on documents 2 and 4 is represented by the broken or dashed arrows or references from Brian's TCB 604 to the LRB 162-5 for document 4, which references an LRB 162-6 for document 2. Also seen in Figure 22C is Brian's TCB 604 referencing Gail's subdatabase (or DBCB) 602, which indicates that the context database for Brian's TCB is Gail's subdatabase.
  • DBCB Gail's subdatabase
  • Anne has started a transaction in Gail's subdatabase. Like Brian's transaction, Anne's transaction can only access documents 2, 3 and 4, unless Gail chooses to dynamically grow her subdatabase by adding more documents to it. At this time, Amie has a write lock on document 3 and a read lock on document 2. This information may be represented by the LRB 162-7 and the LRB 162-8. The LRB 162-7 which is for the SLCB for document 2 would indicate the read lock, and the LRB 162-8 for document 3 would have its mode set to indicate the write lock. At this point in time, Anne can edit only document 3, but she can browse all the changes that Brian is making to document 2.
  • Anne could also browse document 4, and likewise Brian could browse document 3, if desired. It is seen that Anne's TCB 606, in addition to referencing the LRBs 162-7 and 162-8, also references Gail's subdatabase 602 by the context database reference.
  • Figures 23 A-23D illustrate an alternative implementation in which the data structures illustrated in Figure 11 are utilized to carry out the example of Figures 21A-21D.
  • Figure 23A which corresponds to Figure 21 A, there are LCBs 160-1 through 160-4 for the four documents at issue, and each LCB references a corresponding LRB 162.
  • Gail's TCB 650 references the LRBs 162, and also Gail's TCB 650 references or indicates that its context database is the Global Database 192.
  • Gail creates a subdatabase, and by doing this, a database control block 652 is created which is for Gail's subdatabase.
  • Gail's subdatabase DBCB 652 references Gail's TCB 650, indicating that Gail's subdatabase is owned by Gail's transaction, and also Gail's subdatabase 652 references the hash table, array, or other structures 654.
  • This structure 654 has therein SLCBs 164-1, 164-2, and 164-3 for the three documents which are part of Gail's subdatabase.
  • the SLCBs 164 are referenced by references 656, 658, and 660 of the table 654.
  • FIG 23 C which corresponds to Figure 21C, Brian's transaction comes into existence and is represented by Brian's TCB 670 which references Gail's subdatabase control block 652 and indicates that the context database of Brian's TCB 670 or transaction is Gail's subdatabase 652. Brian obtains a lock on documents 2 and 4 which are represented by the LRBs 160-5 and 160-6, respectively.
  • Anne's transaction comes into existence and has Gail's subdatabase as its context database. This is indicated by the context DB reference of Anne's TCB 680 referencing Gail's DBCB 652. Additionally, Anne has certain rights to documents 2 and 3, and this is represented within the data structures by Anne's TCB 680 referencing the LRBs 160-7 and 160-8 for documents 2 and 3, respectively.
  • the LRBs 160-7 and 160-8 would have their fields set to indicate the read only or write capabilities of access which Anne has.
  • Figures 21 A-23D pertains to the locking and sharing of different documents.
  • the invention is not limited to shaiing on a file or document level, but may be utilized to share a single file, document, engineering plans, etc. among a plurality of users or entities.
  • Achieving an implementation in which a single file, document, or other data item is shared within the framework of nested databases disclosed herein relates to the issue of locking granularity, i.e., relating to what the resources the locking data structures or LCBs are representing.
  • the present invention allows the locking of smaller sections of a file or document such as on the paragraph level, on the sentence level, or even going to the extreme of locking individual words, characters or, bits.
  • different portions of an engineering drawing could be shared on a CAD/CAM system or any other system.
  • Figure 24A illustrates an exemplarily screen image 710 of Gail's text editor.
  • the text of the document at issue has four sections indicated by Section 1, Section 2, Section 3 and Section 4.
  • Gail has locked all sections of the illustrated document and has full edit capabilities of the entire document.
  • sample text is illustrated, but any desired text may be used.
  • a screen image 720 again shows Gail's text editor but in this image, Gail has delegated sections 2, 3 and 4 to a subdatabase, and those sections have now become read-only in her editor, indicated by the diagonal lines through sections 2, 3 and 4.
  • a screen image 730 illustrates Brian's text editor.
  • Brian has accessed Gail's document tlirough her subdatabase (in which he has been authorized by Gail to work).
  • Brian has successfully requested write locks on sections 2 and 4, so that they are editable in his editor, while sections 1 and 3 are read-only.
  • the diagonal lines through the read-only sections of the document are for illustration purposes only and there is no requirement to have such diagonal lines crossing through the text. However, in a preferred embodiment, it maybe desirable to show that certain sections are locked and others are not. This may be accomplished by utilizing different colors of the text or background of the text for different types or modes of locks or access capabilities.
  • a color could be assigned to each person and each section or other portion of the document will be colored in accordance with the person or entity having the write lock on the data.
  • a single color may be utilized to designate the section(s) of the document which are read-only.
  • a screen image 740 is illustrated which shows Anne's text editor.
  • Anne has accessed Gail's document through her subdatabase (in which she has been authorized by Gail to work).
  • Anne has successfully requested write locks on section 3, so it is editable in her editor, while sections 1, 2 and 4 are read-only.
  • the invention may be conveniently implemented using one or more conventional general purpose digital computers programmed according to the teachings of the specification, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the art.
  • the invention may also be implemented by the preparation of application specific integrated circuits or by connecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
  • the invention may be implemented using a plurality of computers, computing devices, or other type of devices. These devices may be connected through any type of network in order to communicate data, instructions, requests for data, and any other information related to the operation of the database management system.
  • Such a computer network may be implemented, as desired, using a wired network, a wireless network such as radio frequency, infrared, or ultrasonic type networks.
  • the present invention is envisioned as being implemented using any type of device including personal digital assistants, such as the Palm Pilot, Internet servers, special purpose computers, and any type of Internet browser, including telephonic browsers.
  • the present invention includes a computer program product which is a storage medium including instructions that can be used to program a computer to perform the process of the present invention.
  • the storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, CD-ROMs, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, flash memory, magnetic or optical cards, or any type of media that is suitable for storing electronic instructions including hard disk drives.
  • the present invention also includes the data structures which are described herein, and may be stored in any of the memories or storage mediums discussed in this application.

Abstract

L'invention concerne un procédé et un système de traitement et de gestion des demandes pour l'utilisation concurrente de données. Des base de données servent à créer différents environnements dans lesquels on peut accéder aux données et les modifier. Pour chaque transaction existante, il y a une indication ou une référence à une base de données ou une sous-base de données associée à cette transaction. Il existe également des structures de données indiquant, pour chaque élément de données concerné, quelle base de données ou sous-base de données est associée à cet élément. L'utilisation de structures de données concernant les transactions, les sous-bases de données et les éléments de données permet la création de sphères de contrôle pour les différentes transactions et sous-bases de données. En conséquence, les données peuvent être facilement partagées par les divers utilisateurs. On n'a pas besoin de copies nombreuses de données pour créer les sous-bases de données et le système de gestion de la base de données peut être appliqué en n'utilisant qu'une seule copie des données, bien que l'on puisse se servir de nombreuses copies, si on le souhaite.
PCT/NO2001/000304 2000-07-28 2001-07-16 Procede, systeme et structures de donnees permettant de mettre en oeuvre des bases de donnees imbriquees WO2002010978A2 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
KR10-2003-7001266A KR20030047996A (ko) 2000-07-28 2001-07-16 내포 데이터베이스를 구현하는 방법, 시스템 및 데이터 구조
CA002416909A CA2416909A1 (fr) 2000-07-28 2001-07-16 Procede, systeme et structures de donnees permettant de mettre en oeuvre des bases de donnees imbriquees
AU2001272863A AU2001272863B2 (en) 2000-07-28 2001-07-16 Method, system and data structures for implementing nested databases
MXPA03000756A MXPA03000756A (es) 2000-07-28 2001-07-16 Metodo, sistema y estructuras de datos para implementar bases de datos anidadas.
BR0112967-8A BR0112967A (pt) 2000-07-28 2001-07-16 Método, sistema e estruturas de dados para implementar bases de dados embutidas
AU7286301A AU7286301A (en) 2000-07-28 2001-07-16 Method, system and data structures for implementing nested databases
EP01952068A EP1323071A2 (fr) 2000-07-28 2001-07-16 Procede, systeme et structures de donnees permettant de mettre en oeuvre des bases de donnees imbriquees
JP2002515631A JP2004505380A (ja) 2000-07-28 2001-07-16 ネスト化データベースを実行するための方法、システム及びデータ構造

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/628,728 US6751617B1 (en) 1999-07-12 2000-07-28 Method, system, and data structures for implementing nested databases
US09/628,728 2000-07-28

Publications (3)

Publication Number Publication Date
WO2002010978A2 true WO2002010978A2 (fr) 2002-02-07
WO2002010978A3 WO2002010978A3 (fr) 2002-08-08
WO2002010978A9 WO2002010978A9 (fr) 2003-11-06

Family

ID=24520055

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NO2001/000304 WO2002010978A2 (fr) 2000-07-28 2001-07-16 Procede, systeme et structures de donnees permettant de mettre en oeuvre des bases de donnees imbriquees

Country Status (10)

Country Link
EP (1) EP1323071A2 (fr)
JP (1) JP2004505380A (fr)
KR (1) KR20030047996A (fr)
CN (1) CN1539110A (fr)
AU (2) AU7286301A (fr)
BR (1) BR0112967A (fr)
CA (1) CA2416909A1 (fr)
MX (1) MXPA03000756A (fr)
RU (1) RU2003105686A (fr)
WO (1) WO2002010978A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004006046A2 (fr) * 2002-06-24 2004-01-15 Xymphonic Systems As Procede de collaboration sur des donnees centrales

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7392335B2 (en) * 2006-02-10 2008-06-24 Oracle International Corporation Anticipatory changes to resources managed by locks
US7899999B2 (en) * 2007-06-27 2011-03-01 Microsoft Corporation Handling falsely doomed parents of nested transactions
US7890472B2 (en) * 2007-09-18 2011-02-15 Microsoft Corporation Parallel nested transactions in transactional memory
CN101650646B (zh) * 2009-09-22 2012-02-08 杭州华三通信技术有限公司 一种共享数据一致性的实现方法及装置
US9760584B2 (en) * 2012-03-16 2017-09-12 Oracle International Corporation Systems and methods for supporting inline delegation of middle-tier transaction logs to database
CN104572077B (zh) * 2014-12-12 2018-03-06 百度在线网络技术（北京）有限公司 数据库事务的处理方法及业务系统
KR102016417B1 (ko) * 2016-01-29 2019-09-02 한국전자통신연구원 분산 파일 시스템을 채용한 스토리지 시스템에서 클라이언트 장치와 함께 파일의 분산 잠금을 관리하도록 구성되는 데이터 서버 장치
CN111190908B (zh) * 2018-11-15 2023-09-22 华为技术有限公司 一种数据管理方法、装置及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4965719A (en) * 1988-02-16 1990-10-23 International Business Machines Corporation Method for lock management, page coherency, and asynchronous writing of changed pages to shared external store in a distributed computing system
US5226143A (en) * 1990-03-14 1993-07-06 International Business Machines Corporation Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager
US5551046A (en) * 1991-06-14 1996-08-27 International Business Machines Corporation Method for non-hierarchical lock management in a multi-system shared data environment
US5983225A (en) * 1998-01-26 1999-11-09 Telenor As Parameterized lock management system and method for conditional conflict serializability of transactions

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044370A (en) * 1998-01-26 2000-03-28 Telenor As Database management system and method for combining meta-data of varying degrees of reliability

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4965719A (en) * 1988-02-16 1990-10-23 International Business Machines Corporation Method for lock management, page coherency, and asynchronous writing of changed pages to shared external store in a distributed computing system
US5226143A (en) * 1990-03-14 1993-07-06 International Business Machines Corporation Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager
US5551046A (en) * 1991-06-14 1996-08-27 International Business Machines Corporation Method for non-hierarchical lock management in a multi-system shared data environment
US5983225A (en) * 1998-01-26 1999-11-09 Telenor As Parameterized lock management system and method for conditional conflict serializability of transactions

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004006046A2 (fr) * 2002-06-24 2004-01-15 Xymphonic Systems As Procede de collaboration sur des donnees centrales
WO2004006046A3 (fr) * 2002-06-24 2004-03-04 Xymphonic Systems As Procede de collaboration sur des donnees centrales

Also Published As

Publication number Publication date
AU7286301A (en) 2002-02-13
MXPA03000756A (es) 2004-11-01
WO2002010978A9 (fr) 2003-11-06
CN1539110A (zh) 2004-10-20
BR0112967A (pt) 2004-02-25
AU2001272863B2 (en) 2004-11-18
EP1323071A2 (fr) 2003-07-02
RU2003105686A (ru) 2004-06-20
JP2004505380A (ja) 2004-02-19
KR20030047996A (ko) 2003-06-18
CA2416909A1 (fr) 2002-02-07
WO2002010978A3 (fr) 2002-08-08

Similar Documents

Publication Publication Date Title
US6751617B1 (en) Method, system, and data structures for implementing nested databases
US5983225A (en) Parameterized lock management system and method for conditional conflict serializability of transactions
AU763133B2 (en) Database management system and method for conditional conflict serializability of transactions and for combining meta-data of varying degrees of reliability
US6792432B1 (en) Database system with methods providing high-concurrency access in B-Tree structures
US5276872A (en) Concurrency and recovery for index trees with nodal updates using multiple atomic actions by which the trees integrity is preserved during undesired system interruptions
US6606626B1 (en) Database system with lock manager enhancement for improving concurrency
US9400829B2 (en) Efficient distributed lock manager
US6144983A (en) Method and apparatus for dynamic lock granularity escalation and de-escalation in a computer system
Lomet et al. Access method concurrency with recovery
US7174331B1 (en) Locking mechanism for views associated with B-tree indexes
Lomet et al. Concurrency and recovery for index trees
US20050102255A1 (en) Computer-implemented system and method for handling stored data
US8176022B1 (en) Locking protocol using dynamic locks and dynamic shared memory
US11698893B2 (en) System and method for use of lock-less techniques with a multidimensional database
Ren et al. VLL: a lock manager redesign for main memory database systems
AU2001272863B2 (en) Method, system and data structures for implementing nested databases
Lomet et al. Locking key ranges with unbundled transaction services
AU2001272863A1 (en) Method, system and data structures for implementing nested databases
Haustein et al. Adjustable transaction isolation in XML database management systems
US20060004885A1 (en) Multiple writer support in an OLAP environment
Haustein et al. Optimizing lock protocols for native XML processing
US7321898B1 (en) Locking mechanism for materialized views in a database system
CN111949673A (zh) 基于Hbase存储的分布式悲观锁及其实现方法
Ragunathan et al. Speculation-based protocols for improving the performance of read-only transactions
Lu et al. GLIP: A concurrency control protocol for clipping indexing

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 81/MUMNP/2003

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2416909

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2001272863

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: PA/a/2003/000756

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 018135137

Country of ref document: CN

Ref document number: 1020037001266

Country of ref document: KR

ENP Entry into the national phase in:

Ref document number: 2003105686

Country of ref document: RU

Kind code of ref document: A

Ref country code: RU

Ref document number: RU A

WWE Wipo information: entry into national phase

Ref document number: 2001952068

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1020037001266

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2001952068

Country of ref document: EP

COP Corrected version of pamphlet

Free format text: PAGE 33, DESCRIPTION, REPLACED BY CORRECT PAGE 33

WWG Wipo information: grant in national office

Ref document number: 2001272863

Country of ref document: AU

WWW Wipo information: withdrawn in national office

Ref document number: 2001952068

Country of ref document: EP