KR20030047996A - Method, system and data structures for implementing nested databases - Google Patents

Abstract

The present invention discloses a method and system for processing and managing requests for concurrent use of data. Nested databases are used to create other environments in which data can be accessed and modified. For each transaction present, there is an indication or reference to the database or secondary database associated with that transaction. There is also a data structure for the data item in question indicating which database or secondary database is associated with the item. Data structures for transactions, secondary databases, and data items can be used to create control ranges for various transactions and secondary databases. Thus, data can be easily shared among a plurality of users. The creation of a database does not require a plurality of copies of the data, and the database management system can be implemented using one copy of the data, although a plurality of copies may preferably be used.

Description

How to implement a nested database, system and data structure {METHOD, SYSTEM AND DATA STRUCTURES FOR IMPLEMENTING NESTED DATABASES}

There are inherent conflicts and existing problems when two people or entities want to access information in a database or other place at the same time, or write data to a database associated with the same information at the same time or at the same time. These problems may arise in any type of application that shares data, and in word processing and engineering design, concurrent access may be achieved, regardless of the configuration or situation in which more than one entity wants to use the same data. Generate.

In a database management system, ACID (Atomicity, Consisten cy, Isolation, Durability) characteristics are desirable.

Atomicity means that the results of a transaction (ie changes to the database) are all reflected in the database or not at all. In general, it means to commit or reject a transaction. If the transaction is approved, all changes made to the database by the execution of this transaction are persistently stored, keeping the database in a constant state. If a transaction is rejected, the changes made to the database by the transaction are backed out, once again keeping the database constant.

Consistency means that each transaction only accepts legitimate results for the database. Thus, a transaction must bring the database from one constant state to another.

Independence means keeping events in one transaction secret from other transactions running simultaneously. Concurrent transactions should not interfere with each other and execute as if they had a database in themselves.

Durability means that once you have completed a transaction and approved the results in the database, you will not lose the results if any malfunctions occur later.

While ACID features are highly desirable, having multiple writers of the same data generally requires compromise on the ACID feature. It is very difficult to do what you want to do, whether you need to do it at the same time as everyone or every transaction, while having transactional characteristics. Simply allowing others to access the data while using the data implies conflicts with the ACID characteristics.

The present invention relates to a database management system, and more particularly, to a data management system and a transaction processing system using a lock manager to protect database resources from incompatible use. The present invention also relates to a method of implementing a data management system that allows the use of nested databases based on computer data structures stored in memory. Moreover, the present invention is applicable to certain systems that provide simultaneous access to shared data.

1 is a block diagram of a database management system implementing the present invention.

2 shows a data structure that maintains a track of resources divided into secondary databases.

3 illustrates a plurality of linked lock control blocks and lock request blocks.

4 illustrates a data structure including a subdatabase lock control block (SLCB) used to establish a lock on data items in a secondary database.

5 shows that each transaction belongs to a particular database or secondary database.

FIG. 6 illustrates that in this particular embodiment, the transaction can only access resources in its own database or in a secondary database.

7 illustrates an exemplary implementation of a database control block (DBCB) data structure.

8 illustrates a typical implementation of a transaction control block (TCB) data structure.

9 illustrates a typical implementation of a secondary database in one tier.

10 illustrates an example of using actual transaction fields in a database control block and context database fields and auxiliary database fields in a transaction control block.

FIG. 11 shows an alternative implementation where there is one lookup table per secondary database, the lookup table including a reference to a secondary database lock control block.

12 illustrates a typical implementation of any secondary database in which lock control blocks are included in one array or table.

13 illustrates that the database control block and the transaction control block can be implemented in only one hierarchical data structure arrangement.

14 illustrates an alternative implementation of the lock control block data structure.

15 is a flowchart for creating a new secondary database.

FIG. 16 is a flowchart illustrating a method of populating an auxiliary database even without requiring physical movement of user data.

FIG. 17 is a flow diagram illustrating an alternative embodiment of populating an auxiliary database using the data structure of FIG. 11.

18 is a flow chart illustrating handling of lock requests in the presence of a containment database.

FIG. 19 illustrates an alternative implementation of a flow diagram for handling a lock request in the presence of an embedded database when the lock control block has the alternative structure of FIG.

20 is a flow chart of a process used to terminate the use of the secondary database.

21A-21D illustrate an example where a plurality of users preferably use a single database that includes four word processing documents organized in a secondary database.

22A-22D correspond to FIGS. 21A-21D, respectively, and illustrate a data structure arrangement for performing the example of FIGS. 21A-21D.

Figures 23A-23D correspond to the examples of Figures 21A-21D, respectively, but use a data structure arrangement that is a lookup table or array for each database.

24A-24D show examples of section sharing of a document by a plurality of people with different reading and writing capabilities by using an embedded database.

Accordingly, it is an object of the present invention to allow multiple entities to access the same data. It is also an object of the present invention to lock data in multiple user environments to keep ACID characteristics extensible. It is yet another object of the present invention to have a database management system in which a plurality of users or entities access data through other databases (called databases), ie virtual databases or auxiliary databases. It is yet another object of the present invention to provide a database management system and / or data structure of the system that can implement a secondary database or a virtual database.

These objects are achieved by a memory containing a data structure and a method, system and computer program product that allow concurrency control and locking of data in a plurality of user environments. For an existing transaction, there is an association or reference to the database or secondary database associated with that transaction. The data structure associated with this transaction may be referred to as a transaction control block. The data structure referred to herein as a data control block indicates which database or secondary database is associated with the data item. Furthermore, there is a data structure associated with the actual locking of data, referred to as lock control blocks and / or lock request blocks. The association between the various data structures enables the concept of a nested database, a secondary database or a virtual database. For example, the data structure arrangement can preferably determine the context database of a particular transaction and the secondary database under that transaction execution. In addition, the data structure associated with the transaction may include references to granted lock requests and pending lock requests, which may be represented by a data structure relating to the locking of data. The data structure associated with that virtual database, that is, the database control block, is referenced by the lock data structure so that it can be determined which database or auxiliary database is associated with the lock.

According to one embodiment of the invention, there is a memory for storing data for access by a data processing system. This data is not necessarily the data ultimately desired by the end user, but may be data related to a data structure representing locks and secondary database information. This memory contains a data structure containing transaction information. This data structure is preferably implemented as a transaction control block. This memory also includes a data structure containing lock information of the transaction data. The data structure associated with this database may be referred to as a lock control block and / or a lock request block. Furthermore, there are a plurality of data structures that contain information from a plurality of databases. These data structures may be referred to as data control blocks. These database control blocks are used to associate a particular database or secondary database with a lock or transaction and vice versa in order to appropriately control the nested or secondary database.

The present invention also relates to the creation and use of data structures that implement the concept of nested or secondary databases. The method of marking a lock of a data item includes creating a data structure at the first hierarchy level indicating that the data item is locked by a first transaction associated with the first hierarchy level. The method also includes creating a data structure at the second hierarchical level indicating that the data item is locked by a second transaction associated with the second hierarchical level. Thus, the foregoing steps create a hierarchy that locks controlled data structures, such as a lock control block. Each level of this hierarchy can be used by other databases, secondary databases or virtual databases.

In order to access a data item, first it is necessary to determine whether the data item is currently locked. This determination may include (a) whether a lock of a data item exists at the first hierarchical level, and (b) if in step (a) it is determined that there is no lock of the data item, the determination of the data item at the first hierarchical level. Generating a lock. In step (c), if it is determined in step (a) that there is no lock on the data item, it is determined whether or not the lock on the data item exists at the second level. Also in step (d), a lock of the data item is generated if the lock of the data item does not exist at the second hierarchical level.

In addition to the method of carrying out the functions described above, the present invention includes a system having various means for performing the functions described above. Moreover, the invention further includes a computer program product comprising executable instructions for carrying out the methodology of the invention.

Referring now to the drawings, like reference numerals designate the same or corresponding parts throughout the figures, and more particularly, FIG. 1 shows a database management system (“DBMS”) 100. Transactional operations and management are handled by transaction manager 102 and lock manager 104, both of which are software procedures executed by the data processor or CPU 106 of the system. This transaction manager maintains a transaction table 108, sometimes implemented as a tree structure, to track the identity and state of pending transactions. This lock manager 104 maintains a lock table 110 that is generally implemented using a hash table and various linked lists and / or tree structures (which will be discussed in more detail later). The lock table 110 keeps track of the locks requested on the resources of the database 112. The lock table 110 may store information about the memory address of a transaction, the transaction identification, the type or mode of the lock, the lock parameters, and the database or auxiliary database associated with the lock. This database 112 stores data that allows access to transactions executed by DBMS 100. This database 112 does not need to store data permanently even if it is useful. Alternatively, the stored data can be transiented. Thus, a cooperative transaction on the contents of a database can manipulate data resources that live only for minutes, hours, or days, and will disappear when the system is powered off or down.

DBMS 100 typically includes an additional memory resource 114, one or more system buses 116 interconnecting various system components, and a network interface 118 or other communication interface that handles communication with a client workstation 120. It will include. This memory 114 is not limited to random access memory but can be implemented using any type of memory, preferably both read and write. Moreover, this memory 114 can be used to store the data structures of the present invention. While one is shown in FIG. 1 that may implement the present invention, any predetermined hardware and software may be used to achieve the functionality of the present invention. For example, the present invention may be implemented using any particular operating system that runs any particular type of computer, computer server, and / or personal computer and / or hardware. The components, structures and operation of such hardware are well known.

2, the "lock table" of the preferred embodiment is implemented as follows. The hash function 150 converts a resource identifier (RID) into a hash table address of the hash table 152, and the hash table may be implemented to have a predetermined size. The resource identifier hashed by the hash function 150 may include a resource type or level indicator (eg, indicating whether the resource to be locked is a database, table, page, tuple, etc.) and the starting address of the resource. Each addressable slot 154, e.g., reference 154-1 of a hash table, is null if there are no locked resources corresponding to that slot's hash table address, but the hash value is When there is at least one locked resource corresponding to the hash table address, one of the pointers is included in the list of the lock control block (LCB) such as the LCB 160-1.

The lock manager will allocate (ie, generate and store) one lock control block ("LCB") for each lockable data item that is substantially locked, and an LRB 162 for each lock held by the transaction. One lock request block ('LRB') 162, such as -1). Thus, if a particular database object is locked by three different transactions at a given point in time, one LCB 160 for that object and three LRBs (one per transaction) from that LCB are "hanging" ) "Can be a linked list of". "

Each LCB 160 preferably

A lock ID 170 that will typically include a copy of the resource identifier for the locked resource,

Mode indicator 171 indicating the most restrictive access mode (e.g., browse, read, read in parameter, write, write in parameter, or exclusive) of all locks allowed for the database resource represented by this LCB. Wow,

An optional read parameter indicator 172, preferably in the form of a bitmap, which indicates the logical OR of the read parameters used for read locks (if any) markedly parameterized to the locked resource, and prominent in the locked resource. Optionally, it includes an optional write parameter indicator 173 indicating the write parameter of the write lock (if any).

The details of the read and write parameter indicators 172, 173 constitute an aspect of the present invention, and are disclosed in U.S. Patent No. 5,983,225 to Anfindsen, which is incorporated herein by reference in the database resources represented by such LCB. A request list pointer 174 allowed in the list of LRBs 162 for active resource requests for the request and a list of LRBs (or queues) for the pending (ie not yet allowed) resource requests indicated by this LCGB. Includes a pending request list pointer 175 and a database field 177 that is a reference to the database or secondary database to which this LCB belongs. In accordance with a feature of the invention, the data may be partitioned into a secondary database, a virtual database, or other database referred to herein. By doing so, multiple people or transactions can use the same data. In such a system, the inventor of the present invention preferably knows which database the lock belongs to, and this information can be easily measured using the database 177 field. While this feature of the invention is implemented using a reference such as database reference 177, other implementations may be implemented including including a database name in the LCB. In FIG. 2, database reference 177 represents global database 192. This global database 192 is the highest level database, and the secondary database is represented by DB1, DB2, ..., DBn. Also, for details regarding the use of secondary databases, see the next level LCB that points to a secondary database (a virtual database or a secondary database at another hierarchical level), such as the secondary database lock control block (“SLCB”) 164-1. 178 is described. This reference is represented by either a null or secondary database lock control block at another hierarchy level. The information about these fields is also in the next LCB pointer 176 of the next LCB (if any) that shares the same hash address as this LCB.

The read and write parameters represented by fields 172 and 173 of LCB 160 are not essential to the present invention but represent features that may be used separately or in conjunction with the secondary database features of the present invention. Furthermore, parameters 172 and 173 extend the present invention to the conventional access modes used in DBMSs. Each apparent value of a set of read / write parameter domains represents a corresponding data reliability classification or category. A parameter domain with eight parameter values (each represented by the corresponding bit in the 8-bit parameter field) can define up to eight different data reliability classifications. In another embodiment of the invention, these parameters may be used to read data in spite of the presence of a write lock or characteristics of a database object other than "reliability" such as the type or identification of the application holding the write lock on the object. It can be used to indicate other information that can be used for the application to determine whether or not.

Each LRB 162, representing one grant or pending lock request,

A mode indicator 181 indicating an access mode (eg, browse, read, parameterized read, write, parameterized write or exclusive) for which a resource is accessed or requested by a particular transaction;

A transaction identifier 184 that identifies the requested transaction or holds a lock corresponding to this LRB,

An optional parameter indicator that indicates (if any) the read or write access mode parameters used by the owner of such a read or write lock, preferably in the form of a bitmap, such a field indicates that this lock or request lock Is used only while using the access request indicated by < RTI ID = 0.0 > and < / RTI > Parameter display (182),

And a lockset pointer 185 used to form a linked list of LRBs owned by the transaction, such as transaction T1 identified by transaction ID 184. Linked lists, such as LRBs, can be implemented including other features, such as dual linked lists, which can track the chain of LRBs in both directions. Another alternative to these LRBs is the next LRB pointer 186 to the next LRB (if any) for the same database resource as this LRB.

Typical sizes for the read and write parameter fields in the LCB and the access mode parameter fields in the LRB are 1 to 2 bytes providing 8 to 16 individual parameter values.

Secondary database LCB (“SLDB”) 164-1 may be configured in the same or similar manner as LCB 160-1. Thus, secondary database LCB 164 will be referred to as SLCB to explicitly indicate that this LCB is to be used to control locking of access to data in secondary databases. In Fig. 2, the reference or pointer from the SLCB 164-1 to the secondary database DB1 is a database reference 177 indicating the combination of the SLCB 164-1 and the secondary database DB1. In a similar manner, database reference 177 of LCB 160-1 is referred to as global database 192. However, it is advisable to remove or remove the database reference field 177 from the LCB since the DBMS can be set up to reference the global database 192 with all LCBs, or with a minimum LCB at the first level.

In the present specification, it should be noted that the pointer indicates which of the points from one field to another item. Such pointers are not limited to conventional computer pointers, but may be implemented in the form of a reference or tree structure. In addition, the referenced information may alternatively be included in the data structure itself. Thus, instead of the field 177 referring to the global database 192, information related to the global database 192 may be put in the database field 177. As will be described in more detail below, in a preferred embodiment, the various databases, including the global database 192 and the secondary databases DB1, DB2, .... DBn, are database control blocks ("DBCBs") and end users. Note that does not ultimately contain unwanted data. Instead, a database control block is used to indicate which database or secondary database the lock or lock control block (LCB) is related to.

SLCB 164-1 refers to LRB 162-2, which may be implemented to have the same structure as LRB 162-1. 2 also shows two transaction control blocks T1, T2. This transaction T1 is coupled with the global database, while transaction T2 is coupled with the secondary database DB1. Further, transaction T1 has an allowed block request with reference to LRB 162-1. Similarly, transaction T2 refers to LRB 162-2 which indicates that transaction T2 is locked of data associated with secondary database DB1.

In the present invention, the main entity of the lock manager is a lock control block ("LCB"). In conventional database management systems, the LCB identifies a lockable resource, such as an object, a row (also known as a tuple), or record of an associated table. Such resources are typically identified by object ID ("OID"), tuple ID ("TID"), or row / record ID ("RID"). In short, RID may be used later as a generic term for xID.

In Figure 2, a hash table is shown, but the invention is not limited to the hash table implementation. It is desirable to find the corresponding LCB using the RID, and preferably to properly implement the hash table. As such, any array or other searchable structure may be implemented and the invention is not limited to the use of a hash table.

If a lock is not held by a particular transaction on a given RID, a convenient way of indicating this may not have an LCB for the RID of the data structure. That is, the LCBs that can be reached from the hash table represent only a subset of all lockable resources, such as lockable resources, which may occur by at least one transaction in time at this point.

As an alternative to linking LCBs in one direction, a dual linked list can be implemented to track the chain of LCBs in both directions. For each lockable resource, there may be a plurality of transactions that hold the lock on the resource at query time. Each granted or pending lock request is indicated by a lock request block ("LRB"). Preferably each LRB quotes or references its LCB backwards. Such features may not be included in the drawings for clarity and space. The LRB chains can be implemented using a dual linked structure to track the chain of LRBs in either direction. Furthermore, the first LRB may refer to the last LRB of the chain of LRBs. This improves performance whenever it needs to be placed at the end of the chain as soon as possible (eg when a new LRB has to be inserted at the end of the pending list). For example, to implement this feature, the LRB 162-5 of FIG. 3 will refer to the LRB 162-7.

3 is an example of a set of data structures that may be used in the present invention. However, DBCBs are not explicitly shown. These transaction control blocks (“TCBs”) T1 and T2 represent a transaction. A transaction can have many locks and many LRBs, while an LRB preferably belongs to only one transaction. For each TCB, a set of LRBs is maintained. The dashed lines in the figure are used to indicate the relationship between LRBs and from TCBs to LRBs. Also, LRBs can be made in a doubly linked list, and LRBs can be implemented such that each LRB appears in its transaction control block. For example, in this case, each of the LRBs 162 of FIG. 3 will represent one of the TCBs T1 or T2.

As can be seen from the LCB and SLCB data structures of the present invention, the LCB is used to represent lockable resources and databases. That is, the LCB represents a lockable resource in a particular database (either a global database or a secondary database therein).

4 shows a data structure for locking and represents only one database control block (“DBCB”) since each LCB (or SLCB) is associated with only one database. For example, in FIG. 1, SLCB 164-1 refers to DB1, SLCB 164-2 refers to DB2, SLCB 164-3 refers to DB1, and SLCB 164-4 refers to DB1. See DB2. If desired, it can be avoided to have a database control block for the global database since each LCB at the lowest hierarchical level belongs to the global database and defaults can be considered for the LCB and transactions. In that case, it is desirable to use a reference from the LCB and TCBs to indicate the relationship with the global database.

4 also shows how any number of levels in the secondary database are generated. As described above, the SLCB can be implemented to have the same structure as the LCB, and this leveling can only be done in this application to distinguish between the LCB for the secondary database and the LCBs of the global database. However, some memory can be saved by implementing SLCBs without the "see next LCB" used to link the LCBs together. However, if desired, the SLCBs may be linked to each other in a single direction or double linked if desired. In FIG. 4, the LCBs 160-1, 160-2 are first level LCBs and are associated with a global database. The SLCBs 164-1 and 164-3 may be second level LCBs or considered as first level SLCBs. SLCBs 164-2 and 164-4 are third level LCB or second level SLCB. The selection link between SLCBs at the same level is indicated using dashed arrows or references, and may also be implemented such that SLCB 164-3 can refer to SLCB 164-1.

Figure 5 illustrates belonging to a single database per transaction in the preferred embodiment. Each of these transaction control blocks T1, T2, T3, .... Tm refers to a single database control block. Thus, it is possible to determine the level of database or secondary database associated with a particular transaction.

6 shows an exemplary data structure that accesses only resources in its database. For example, for a transaction T1 that references the global database 192 using a solid arrow, the transaction T1 uses a dashed line table to match the first level or LCB level referenced by the hash table 152. See associated LRBs 162-1 and 162-3, respectively. In addition, transaction T2 and its transaction control blocks are referenced or are part of the secondary database, and are also associated with the second LCB level or the first SLCB level using dashed arrows and correspond to DB1 LRB 162-2, 162-4). In a preferred embodiment, the transaction executes in the context of one database and only one database. Also, it is desirable for a transaction to prohibit access to resources outside the scope of the transaction's database. At that implementation level, this results in LRBs of the transaction that are bound to or belong to LCBs (or SLCBs) that refer to the same database control block as the transaction control block of the transaction references. For example, in Fig. 6, T2 is executed in DB1. Thus, LRBs 162-2 and 162-4 of T2 belong to LCBs SLCB 164-1 and 164-2 that refer to the same database DB1.

7 illustrates a typical implementation of a database control block (“DBCB”). In the preferred embodiment there is no request to the DBCB to ultimately store the data desired by the end user, but the purpose of the DBCB is to indicate which database or secondary database the lock belongs to, as indicated at least in part by the LCB or SLCB. will be. DBCB 202 of FIG. 7 includes an identifier field 204 shortened as an ID. This field indicates the name or identification of the DBCB. The active transaction field 206 (abbreviated Act Tx) may track up to each transaction that is active at this point in the database or secondary database upon querying from the DBCB. For example, this is desirable if the owner of the secondary database wishes to allow or terminate the secondary database. The system must determine which active transaction is in the secondary database, and if the list of active transactions is not empty, the owner of the secondary database indicates whether other work is in progress in the secondary database, and at that point You should receive an alarm asking if it is desirable to exit. It is desirable to give the responsible entity terminating the secondary database the possibility to change its termination decision.

Alternatively, the system can be implemented such that the secondary database cannot be terminated if an active transaction is running internally. In such a case, the transaction must proceed to terminate the secondary database only when there is no active transaction. Without this check, it would be undesirable for the system to abort a transaction for the characteristics of the data management system. The active transaction field 206 may include a single reference that is part of one linked list that includes a plurality of references, one list of all active transactions, or may include the name or other identification of an active transaction. have. Additionally or alternatively, the active transaction field may be implemented using a dual linked list that references each active transaction to the database or secondary database when there is a contradiction.

Since the owning transaction field 208 (abbreviated Own Tx) is referenced in the transaction being created, it owns the DBCB at the time of query. For a global database, this field can be set to be a null reference, and for a secondary database this field will refer to its creator / owner transaction control block. Super database field 210 (abbreviated to Sup DB) refers to the DBCB representing the database that is part of this database.

Secondary database field 212 (abbreviated, Sub, Db) refers to a set of DBCBs representing the secondary database of this database. The next database field 214 (abbreviated Next DB) refers to the next DBCB within the same level in the database hierarchy. The previous database field 216 (abbreviated Prev DB) refers to the previous DBCB within the same level in the secondary database layer. The next DB and the previous DB are used to create a dual linked list of DBCBs within a given level at the secondary database layer. Thus, secondary databases with the same parent database are linked together in such a list. Three points or ellipses in DBCB 202 indicate that additional fields may be included in the DBCB.

The purpose of the DBCB is to pinpoint the place where a particular thing happens, such as a lock, in the resource or database layer. Thus, the relationship between the rest of the system and the secondary database can be easily determined.

As for the DBCB described above and the transaction control block 'TCB' which will be described in detail later, there are a plurality of fields (not shown) included in this data structure. In order to maintain a plurality of manageable and understandable references, it is not necessary to describe all the references. Thus, the fact that a diagram does not contain a reference should not be interpreted to mean that the reference is not there, and similarly, the fact that a data structure contains a particular reference or field means that such a reference is an absolute requirement of the data structure. It should not be interpreted. DBCBs preferably form a hierarchy. However, other implementations without DBCB arrangement in one layer are possible.

8 illustrates a transaction control block (“TCB”) data structure 222. This data structure is used to indicate an active transaction, to indicate which database or secondary database the transaction belongs to, and to determine the locked resources and lock state of the transaction.

The TCB has, for example, an identifier field 224 that identifies the name of the transaction. The context database field 226 (abbreviated Ctxt DB) is used to refer to the DBCB of the database that represents the scope or context of the transaction at the time of query. This can be determined at transaction creation. According to one embodiment of the present invention, from the time a transaction is born to the end of the transaction, the transaction executes all its operations within a single database, living its life. In a preferred embodiment of the present invention it operates efficiently and suitably by using rules in which transactions exist at the beginning of their lifetime in a single context. Thus, the context database field 226 can be used to indicate the scope or context of the transaction in the query. For example, the context database field 226 refers to a global database, meaning that a transaction corresponding to a TCB is executed in a global database, or it has a global database as the context database.

Secondary database field 228 of FIG. 8 represents a set of secondary databases that generate such transactions. Note that these fields may be empty or may refer to nulls. Since a transaction can be created, it owns multiple secondary databases. Depending on the operation performed, it may be desirable to determine how many secondary databases exist in a particular transaction. Thus, when you want to terminate a transaction, it is desirable to know what secondary database exists before executing such termination. Similarly, as described above, it is desirable to know the secondary database for the database control block.

Field 230 represents the TCB's allowed lock request, and field 234 represents the TCB's pending lock request. These fields 230, 234 may be implemented using references from the TCBs to the LRB shown in the figure, eg, FIG. 6.

Super transaction field 236 may preferably be used to maintain a hierarchy of transactions or TCBs. Super transaction field 236 will reference or point to the transaction with the higher hierarchy than the transaction in question. For example, the transaction field 236 will be used to reference the transaction that created or allowed to create the transaction in question.

9 shows a relationship between DBCBs and a relationship between DCBC and TCB. This data structure is used to control locking of resources. In Fig. 9, by not showing the hash tables, LCBs, SLCBs and LRBs, the diagram was not overly complicated. However, data structures typically appear in the system. 9 shows TCBs (T1, T2, T3, .... Tm). Also shown are DBCBs 240, 250, 260, 270, 280, 290, 300. As such an example, a hierarchy of DBCBs can be observed. For example, DBCB 240 is the best DBCB in the hierarchical DBCB structure and corresponds to global database 192. With respect to DBCB 240, ID field 241 will indicate whether this DBCB is a global database. The Own Tx field 243 points to null because DBCB does not need to identify the owner or owning transaction of the global database. Similarly, Sup DB field 244 also points to null because there is no super database for the global database.

Sub DB field 245 refers to the collection of secondary databases for this database, in which case it refers to DBCB 250. At the global database level of this particular example, since there are no other databases at the global database level, the next DB field 246 and the previous DB field 247 each point to null. Although the diagram is not simplified by simply showing the active transaction field 206 shown in FIG. 7, in the preferred embodiment, an active transaction field may be used as described above.

At the hierarchical level below DBCB 240 are DBCBs 250 and 260. Not all fields of FIG. 9 will be described by themselves. However, with respect to DBCB 250, it is shown that owning transaction 253 refers to T2, which is a global database such that super database 254 for DBCB appears in DBCB 240. The secondary database for this DBCB 250 is pointed to by the reference Sub DB 255 which references DBCB 270. Secondary databases 280, 290, and 300 of database 250 are linked to secondary database 270. The next DB field 256 refers to DBCB 260 and the previous DB field 257 refers to null.

Regarding DBCB 260 at the same hierarchical level as DBCB 250, the owning transaction 263 is T3, the super database 264 refers to DBCB 240, and the Sub DB field 265 refers to null. There is no secondary database for DBCB 260 indicated by, and there is no next DB as indicated by field 266. Previous DB field 267 refers to DBCB 250. Based on the foregoing description of DBCBs 240, 250, 260, it is evident that DBCBs 270, 280, 290, 300 are at the same hierarchy level below the hierarchy level of DBCBs 250, 260.

For typical DBCBs, a super database field will generally refer to one super database in addition to the global database, which will not refer to a particular super database. Such a reference may represent that hierarchy. 9 illustrates only one example of how DBCBs can be arranged during a particular row of transactions, and the exact hierarchy of FIG. 9 is not required.

If a transaction creates a secondary database, that secondary database will be created based on the context of the creating transaction. In Fig. 9, transactions T2 and T3 are preferably executed in a global database because it is not possible to create an auxiliary transaction belonging to that global database. Thus, the fact that DBCBs 250 and 260 have a global database represented by DBCB 240 as an advanced database indicates that the Owing transaction has a global database as its scope or context. Furthermore, as described above, there is preferably only one super database for each DBCB, but it is preferred that the secondary database has a specific number. However, alternative implementations may not have such a requirement.

9 shows a double linked list between such DBCBs, while DBCB 250 refers to DBCB 260, and DBCB 260 refers to DBCB 250. Relationships are not mandatory but can be used for other implementations such as tree structure implementations. For example, it may be a reference or pointer from a DBCB that points to or refers to an individual object to represent a set or list of some structures indicating the location of the DBCBs. This alternative implementation may add other data structures to the data structure arrangement. Such alternative arrangements can complicate data structure placement, but doing so may be an advantage. One such example may preferably remove the next and / or previous reference of DBCBs.

FIG. 10 shows additional details of the TCB and DBCBs not shown in FIG. 9. These details are omitted from FIG. 9 for clarity, and prevent the drawing from becoming too cluttered. Similarly, features of DBCB included in FIG. 9 have been omitted from FIG. 10 for clarity. In FIG. 10, the active transaction field is shown in DBCBs, and the context database and auxiliary database field are used to illustrate the TCBs. These fields of FIG. 10 illustrate the relationship between DBCB and TDB in a more detailed manner.

It is preferred that the DBCB track its own transaction, which is illustrated in FIG. 9 and preferably tracks the active transaction of the secondary database. This function is performed by an active transaction reference or field in the DBCB. As shown in FIG. 10, DBCB 310 has an identification field 311 and an active transaction field 312. This active transaction field 312 refers to the TCB 320. Accordingly, the owner of the secondary database corresponding to DBCB 310 may determine whether the transaction corresponding to TCB 320 is an active transaction to DBCB 310. Further, it can be seen in the rightmost part of the TCB 320 that the TCB 330 is referenced and the TCB 330 refers to the TCB 340. TCB 340 also references TCB 330 which references TCB 320. Also, the context database fields of each TCB 320, 330, 340 refer to DBCB 310.

When a transaction is created, started or started, the transaction preferably has some kind of context to execute. In the classical context and in the prior art, this setting is always a global database. However, as the nested database of the present invention, a transaction can be initiated and executed in a global database, and a transaction can be initiated in a secondary database. Preferably data outside of the secondary database on which one transaction is invoked is inaccessible, and preferably the lock manager can determine the database on which this transaction is running and is referred to as the context database. If the resources requested by one transaction are outside of the context database, the request to access this information may be negated by the lock manager, preferably. However, as an alternative, you can dynamically grow that secondary database at query time. Preferably, this dynamic growth can occur on the right side, and preferably, the growth can be triggered automatically (eg without interruption of the user). This growth can occur in a manner similar to the process of FIG. 16 showing how new data items are generated in the secondary database. If the data requested is part of a context database, the resource belongs to an accessible database, and the next question to evaluate is whether there are any conflict locks on that resource. If there are no conflicting locks, the lock manager can grant the lock request. Thus, the data structure of the present invention can indicate whether a resource is accessible and determine whether the resource is locked.

Referring back to FIG. 10, the Sub DB field 323 of the TCB 320 refers to the DBCB 348, the Sub DB field 333 of the TCB 330 refers to the DBCB 346, and the TCB ( It will be appreciated that the Sub DB field 343 of 340 refers to the DBCB 347. With respect to DBCBs 348, 352, 356, the super database pointers or references of these DBCBs refer to DBCB 310. The DBCB 348 refers to TCB 360 using its active transactional reference. TCBs 360 and 364 refer to DBCB 348 using context database references corresponding to them, respectively. The detailed structure of the simple DBCB and TCB fields of FIG. 10 has been omitted for clarity in order to prevent excessive clutter due to references.

11 illustrates an alternative implementation of the data structure used to control and monitor locks of resources. 2, 4 and 6, in the case where the lock manager handles a lock request for a lock of a specific resource of a specific database, the resource ID ("RID") is first used in the global database. The LCB for a given resource will be found. Then, if necessary, the "next level LCB" reference will be used to find the LCB for the same RID, but in special cases the database or secondary database identified by the lock request to be processed. An alternative embodiment of FIG. 11 (also an alternative embodiment of FIG. 12) allows a sequence of events in reverse as compared to previously described. That is, the data structure of FIG. 11 allows the lock manager to first locate a database, which is represented by the DBCB, and then the RID within that database. This is done to have one lookup table per DBCB rather than a single global lookup table such as the hash table described previously.

In FIG. 11, in addition to referring to their owing TCB, DBCBs refer to a lookup table that provides access to the RIDs included in the database upon query. For example, DB1 refers to table 380, DB2 refers to table 390, and DBn refers to lookup table 400. Each lookup table 380, 390, 400 references an SLCB that provides information about the lock of a particular data item. Although not shown in FIG. 11, the LRBs may be used for the lock request and the pending lock request granted to the SLCBs in the same manner as the method used in the above-described embodiment.

The secondary database lookup tables 380, 390, and 400 may be implemented as hash tables, but not otherwise. For example, auxiliary data lookup tables may be implemented using a constant sized array of LCB references. This implementation is advantageous in the case of fixing the size of the auxiliary data at the time of generating the auxiliary data, and can also be alternatively implemented using a dynamic size array (probable array) of LCB references. When using a hash table as a secondary database lookup table, this hash table may be allocated with fewer entries than the global database hash table. When using hash tables as a secondary database lookup table, for example, as shown with respect to lookup table 400 with reference 402 referring to SLCB 164-5, which refers to SLCB 164-6, for example. It may have a chain of LCBs for a given hash table. In the alternative embodiment of Figure 11, since the LCBs are organized in different lookup tables, the "next level LCB" field of the LCB or SLCB is no longer needed. Thus, from a given entry in one such lookup table, the linear structure of the LCB opposite to the hierarchy of LCB and SLCB of the previous embodiment is accessed. In Fig. 11, each secondary database DBCB refers to its own TCB, and each TCB also refers to the DBCB it contains. The data structure of FIG. 11 does not eliminate the use of super database references, even though these references are not shown in FIG. 11 or 12.

In FIG. 11, there are bidirectional references between the TCB and the DBCB that represent information related to the context database for a transaction. That is, referring to T1, for example, T1 points to a global database 192 that directs T1 to run in the global database or to have a global database as a list database of T1. Referring to DB1 through T1, this reference indicates that DB1 is owned or created by T1, T2, T3, and T4, and all reference DB1 indicates that these transactions are executed within the scope or context of DB1. In Fig. 11, T4 is a creator of DB2 referring to DB2 through T4, but shows that T4 is executed in DB1. From this information, it can be determined that DB2 is the secondary database and included in DB1. It should be borne in mind that FIG. 11 is only one example of a secondary database system and may be illustrated in other ways. However, as shown in FIG. 11, it is a subset of DB1 because it is the connection through T4 that replaces DB2. 11 also shows that T5 and T6 are executed with DB2 in their context. T6 creates a DBn, and T7 and T8 run within the DBn.

12 illustrates another modified implementation of the present invention. As the size of the secondary database becomes smaller, the secondary database can be implemented with fewer lockable resources, so that the secondary database can preferably be implemented with a constant size, and the lookup tables 410. 414, 416 are preferably May be implemented as an array of LCBs. Since the LCBs are for the secondary database, the LCBs of FIG. 12 are shown as SLCBs (“secondary database lock control blocks”) 164-1-164-20. Arrays of SLCBs can be used as opposed to an array of references or a hash table of LCB references. Note that the hash table 152 may be preferably implemented in the same manner as described with respect to the embodiment above. By implementing a hash table for a global database, a large number of LCBs can preferably be used for the global database. If a particular use of the secondary database is known or unknown, it may be desirable to limit the number of items in the secondary database to any number, such as 20 data items. This number is preferably large or small. However, the number is constant and can be implemented to have 20 pieces of memory each capable of holding one full SLCB. In the case of using only a portion of the allocated memory, the unused portion is wasted, but it does not get too large, and the advantage of not dealing with dynamic memory allocation every time a new LCB is introduced is obtained. It can also have a chain of LCBs, such as a linked list or a doubly linked list without a lookup table, and can perform a sequential search of a pointer or reference chain whenever there is a need to locate a particular LCB.

13 illustrates a layer that includes all data structures associated with DBCBs and TCBs. According to the invention, one can see a transaction and a database having the same kind of "thing". This allows you to view the database as a manual transaction. Thus, if the database is viewed as a passive transaction and the above described as a transaction (e.g. T1) is leveled as an active transaction, then the integration scheme of DBCB and TCB in a single layer data structure is possible.

13 shows ATCBs and PTCBs referred to as active and passive TCBs. Active TCB ("ATCB") corresponds to the TCB described previously, and passive TCB ("PTCB") is another name for DBCB. In FIG. 13, the root of the layer, which may be referred to as the database / transaction layer, is the global database PTCB 420. This node corresponds to the global database data structure 192 described above. At that layer, although a PTCB is not commonly or commonly used to have another PCTB as an intermediate parent node, any node may have a particular type of child node. Although different from the foregoing, the starting point of the hierarchy is a global database that is the root of the hierarchy, after which the database / transaction hierarchy is dynamically developed (growing and contracting) in a nearly perceptible way in which transactional and auxiliary databases are created and terminated. )can do. This means that as long as there is a system for doing transaction management and lock management, PTCB for the global database can appear, while all other nodes can be relocated. In this case, the PTCB for global database can be implemented to appear permanently. The integrated structure of FIG. 13 can be used in the implementation described above. This may be implemented to have a global lookup table that provides access to all LCBs, or it may be implemented to have a lookup table for each PTCB that provides access to an LCB belonging to a PTCB upon query.

Referring to FIG. 13, global database PTCB 420 is shown to be at the highest hierarchical level. That is, under the global database PTCB 420 there are three transactions: ATCB 422, ATCB 424 and ATCB 426. These three ATCBs are top level transactions with the global database PTCB as their intermediate parent node. All other transactions and ATCBs in the layer of FIG. 13 may be considered secondary transactions. The reason for implementing the data structure relationship shown in FIG. 13 is that the inventor considers the secondary database to be a passive transaction and determines that the secondary database will be a secondary transaction, since the secondary database can always be created by an active transaction. will be. The advantage of the hierarchy and integration of the data structure shown in FIG. 13 is that it is potentially simplified compared to the arrangement shown in FIG. This simplification may occur because of a single layer, rather than having a pointer or reference that crosses back and two other layers of TCB and DBCB. Rather than the database control block distinguishing between its own transaction and its super database, the data structure can be implemented such that only one of the two fields is currently needed, and the system can be implemented to include only super nodes. . For example, referring to FIG. 10 where a transaction control block has a pointer or reference to a context database, a previously implemented data structure is preferably implemented to have another pointer or reference in a super transaction even if it is not necessary. According to the embodiment of Fig. 13, such super transaction and context database references or pointers may be combined into only one reference. Hash tables, lookup tables such as LCB, SLCB and LRB are used in this embodiment in a manner similar to that used in the above embodiments.

When executing lock request processing steps similar to those executed by the previous embodiment, for processing, it may be desirable to proceed from the TCB to the LCB or vice versa. As before, the answer may be determined by the TCB or ATCB referencing the PTCB corresponding to the DBCB. Alternatively, it will proceed to the top of the hierarchy until the PTCB is located. In either case, one can quickly progress from the transaction control block to the data control block of the transaction. In this regard, there are two options for using a RID as a hash table to find a reference LCB for a query and then a database LCB for a query, and then proceed to DBCB and then for one desired RID. You can proceed to the database control block or hash table used to retrieve the LCB. With regard to the structure of the PTCB, this structure can be similar to the DBCB described above. However, PTCB would preferably be implemented by combining the owning transaction with the DBCB's super database field, which can be said simply to be superior. With regard to the implementation of ATCBs corresponding to the aforementioned TCBs, the context database field 226 of FIG. 8 may be combined with the super transaction or parent transaction field of the TCB of FIG. 8. Thus, even if further changes are made, it is advantageously possible to implement an ATCB very similar to a TCB.

Each of the embodiments described above preferably used an LCB or SLCB that referenced the lock request block of the LRB. By modifying or adding this implementation, it is possible to replace the LRBs with the request bit map and the pending request bit map allowed in the LCB or SLCB. Referring to FIG. 14, a modified implementation of LCB or SLCB is shown as data structure 460. This data structure is abundant control blocks in which the LCBs (and SLCBs) contain more information than conventional LCBs (and SLCBs) by integrating the information stored in the LRBs into the LCB. The data structure of FIG. 14 is based on or similar to the data structure of FIG. 3 shown in US Pat. No. 5,983,225, which is incorporated herein by reference.

This data structure 460 typically includes a lock ID field 462 that will contain a copy of the resource identifier for other identification of the locked resource or part of the resource in question. The mode field 464 represents the most restrictive access mode of all locks granted for the database resource represented by this LCB. The allowed request bit map field 466 and the pending request bit map field 468 each contain a bit map of sufficient size (e.g., 64 bits or 128 bits), so that the maximum number of concurrent transactions (e.g., Or sub-database level). Each transaction is assigned to one of the bitmap transaction identifiers. The allowed bit map 466 includes an aggregate bit for each active transaction that granted the lock resource indicated by the LCB (or SLCB) 460. Similarly, the hold request bit map 468 includes an aggregate bit for each active transaction that indicates a hold lock request (or access request) on the resource by the LCB 460. The database field 470 refers to a DBCB representing a database for a resource corresponding to the LCB 460. In this embodiment, as in other embodiments, there is only one physical copy of a given record or object, but the system can be implemented such that the record can be accessed from more than one database, and at one point in time If one or more databases are inaccessible, they can be accessed at different times. Thus, when a transaction accesses a resource in question, it will preferably indicate which database accesses that resource, and will be one LCB (or SLCB) for each database to which the resource in question belongs, and the LCB (or SLCB). ) Should preferably be able to clearly identify the database in question. This is for database field 470.

With respect to the next level LCB 472, this field refers to the next level LCB in the same way as shown in Figs. 4 and 6 with reference to higher hierarchical level SLCBs. Field 474 further indicates that fields may be included in LCB / SLCB 460. For example, the read and write parameter bit maps, as shown in element 172, 173 of FIG. 2 of US Pat. No. 5,983,225, indicate an access mode that becomes the allowed read and write parameters on the database resource represented by LCB 460. Can be used to wager. In addition, other fields may be included in region 474 of LCB 460. The next LCB field 476 may be used to indicate the next LCB and may correspond to field 176 of FIG. 2. In addition, this database field 470 and next level LCB 472 may be implemented in a manner similar to database field 477, and the next level LCB field 178 may be implemented with respect to FIG. An alternative implementation of LCB or SLCB 460 may be replaced with one of the preceding figures using LCB or SLCB, which may eliminate LRBs that are preferably used in that embodiment.

The present invention relates to a transaction, where a transaction can be considered a logical unit of work. Such a transaction may execute a command of the program based on a person's setting at the terminal performing the work, or based on executing or submitting an existing computer program. A secondary transaction relates to the idea of working in one transaction, working under one transaction, or working in conjunction with one transaction. Dividing one transaction into auxiliary units may be considered to create a secondary transaction. In a preferred embodiment, a transaction is independent of other transactions and can be a voluntary unit of work. Alternatively, the secondary transaction can be an involuntary or non-independent transaction. Thus, auxiliary transactions can be considered part of a transaction at a high level.

A database can be thought of as a process of collecting data. In addition, the secondary database is also a process of collecting data, but the secondary database can generally be considered to be dynamically created and non-resident entity. In a preferred embodiment, the secondary database can be implemented to live while the transaction it created is live and only if the entity that created the secondary database does not exist, and the secondary database may also not exist. This secondary database may be considered to be associated with a control area that has a barrier or line installed around a subset of the data. This secondary database can also be considered a virtual database. Here, the database may be used to refer to a secondary database or a virtual database. This auxiliary database can be considered virtually in the sense without shape. By implementing the present invention, there is no need to physically copy the data of the secondary databases individually. Thus, data belonging to the global database can be copied once, and at the same time, it can belong to one or more secondary databases corresponding to the global database control block 192 without having to physically copy the data.

This data may preferably be stored in a global database such as the database of FIG. 1. The global database 192 is preferably implemented as a database control block used during the process of managing and operating the lock manager of the DBMS. In order to obtain the data actually stored in the database, the global database 192 and other DBCBs, DB1, DB2, .. DBn are not directly used as entry points for obtaining the predetermined data, and the data is preferably such It is not stored in the data structure. In an embodiment of the present invention, it is preferable to proceed through the LCB and SLCB, preferably to obtain the data (to obtain the lock information used to access the data). If you have a record ID (“RID”) and you want to access a particular record that corresponds to the RID, access to that record will be in a given database or secondary database. As a basic method, for example, with respect to the data structure shown in Figs. 2-10, a hash table is used to obtain an entry for the RID which, when found, points to an empty chain of LCBs or LCBs corresponding to a particular RID. LCBs belonging to other RIDs can be ignored. If the secondary databases are not interested or are at the level of the global database, the LRBs corresponding to the LCB found through the hash table are checked to see if there are any lock conflicts and if the lock request can be granted. In such a case, the LRB corresponding to the requested lock will be derived into the chain of allowed LRBs, and access to the data will be allowed. At this time, it is well known but not shown and can proceed to other components of the system, and can be referred to as a buffer manager or other item that can be accessed by the disk and physical address from which records are to be retrieved to obtain actual data. If there are embedded or secondary databases, database control blocks are used to obtain access permission of the data. The data control blocks are preferably not used to directly access the data. As mentioned above, to obtain data, the hash table is used to find the corresponding LCBs to which the hash table hangs off as described above. An entry for the RID is obtained at the time of inquiry and moves to the right side of the figure to find the LCB for the RID at the time of inquiry. Reference is made to FIG. 4 to see the data acquisition method. There are first level LCBs 160-1 through 160-2 in FIG. From hash level 152 of FIG. 4, reference 154-1 is directed to LCB 160-1. LCB 160-1 refers to global database DBCB 192. If a portion of the data is put in database 2 (e.g. DB2), or if a transaction is running in the context of database 2 at query time, then 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. SLCB 164-1 references DB1, not the database of interest. Thus, if the LCB / SLCB layer continues from the first level to the third level of LCBs, it can be seen that the SLCB 164-2 refers to DB2 and is at the correct LCB level since it is interested in DB2. The lock manager checks in SLCB 164-2 which locks appear in these databases and these resources. If a new lock request is compatible with something already there, the lock request is granted. When the lock request is granted, the lock is acquired on the data, but the data itself must be accessed. In order to access that data, the DBCB is not used in the preferred embodiment. The database control block is preferably used for concurrency control and is used by the lock manager, but preferably not by a buffer manager or some other mechanism in the system that retrieves data out of it. In a preferred embodiment, the database control block is just a control block, does not contain data, and contains control information. Thus, when the lock is granted, the system provides an indication that a particular transaction refers to a particular RID. According to the prior art and database implementations, for example, there is an indication that locking to data is allowed, and a buffer manager or other entity can be used to obtain data identified by the RID. The buffer manager preferably does not need or uses DBCBs to obtain data. Acquiring data is a matter of the physical access path on the disk where certain data remains.

Although alternatives plan the use of more than one copy of data, in the preferred embodiment there is only one copy of data. The record or object of anything you want exists as a copy. There are physical addresses on the disk, the buffer manager indicates the physical address that provided the RID, and what auxiliary database the data belongs to and in which case the physical address is the same is not important to the buffer manager.

SLCBs and LCBs are shown including a reference or pointer to a DBCB. It should be noted that in alternative embodiments, such references or pointers may be removed by including fields within the LCB or SLCB with numbers or identifications indicating that the SLCB belongs to a particular database or secondary database. Other implementations may be made with reference to LCB or SLCB.

The data structures used to implement the secondary database of the present invention begin to cycle with well known concurrency control techniques such as locking. Cycling again applies certain principles, and in this particular context is done by launching a global database that stores a wide collection of data items, such as word processing or engineering design or CAM / CAM design documents or structures. The concurrency control is performed by locking one person or a transaction from corrupting or making inappropriate the data the other person is working on. The principle according to the invention is to create a nested or secondary database, which can be considered as a mini database, to carry out the same basic concepts and locks on the secondary database done against the global database. Thus, the present invention applies the principles of the global database to the virtual collection of secondary databases. Thus, the present invention applies the principle of iterative concurrency control to the problem of collaboration, thereby creating a virtual database or virtual sandbox environment. For such a virtual environment or ancillary database, the present invention allows for normal concurrency control, and the setting up of arbitrarily complex patterns of interaction between two or more users who wish to cooperate.

If one wishes to cancel the modification of the data or to return to the previous state of the data regarding the spontaneous nature, the present invention can be implemented to keep a log of everything that is done per data within the scope of the transaction. The contents of the log can forward and backward recover any item that is modified. This is known as resilience and is a well known implementation technique. However, most techniques for cooperating between multiple writers will sacrifice the spontaneity of a transaction by dividing the transactions into a plurality of smaller transactions. Examples well known for this technique include open nasted transactions, so-called saga. It can recover in much less atomic transactions than this, while its resilience is compromised for the logical unit of very large work that constitutes a transaction as the user wants to see it. For this reason, you need to introduce a reward transaction, which is a transaction that must be written by the application developer. In other words, this is an essential technique for recovery.

This is the opposite of the case of nested databases, whose resilience is not compromised and the use of compensating transactions is unnecessary. Moreover, well-known techniques can be used to implement resilience in the presence of embedded databases, and there is no need to develop new algorithms, data structures, or techniques for this purpose. Maintaining resilience at all levels of the combined nested database by providing this by standard techniques is an advantage of the present invention over other tasks that have the problem of collaborative tasks.

In a preferred embodiment of the present invention, in order to create or initiate a secondary database, it is preferable to record a lock on the object or secondary database, preferably at query time. The transaction establishes the scope of control that brings certain objects dynamically, and the manipulation of those objects is possible based on the nature of the scope of the control at query time. Can be modified. Write locks allow the writing, deletion, insertion, and modification of data and, in accordance with preferred embodiments, request the creation of a secondary database in advance. This secondary database can generate a database lock as opposed to a write lock. If you do a database lock, it is impossible to do everything possible with a write lock, and the database lock can be attributed to the entity that holds the write lock to actually give up some rights. While some rights are waived, the advantage of relinquishing those rights and creating a secondary database is to create a separate situation of concurrency control, because the owner of the secondary database is willing to take objects of the secondary database to another person or entity. Because I share with.

The lock manager for a particular transaction allows that transaction to live its life within the scope of a particular database. Thus, the present invention can be implemented to use a recursive algorithm that recognizes transactions or auxiliary databases with different scopes. The present invention differs from the parameterized management system described in US Pat. No. 5,983,225, although implemented according to the technique of US Pat. No. 5,983,225 to make the system more powerful and additional features. The use of the nested or nested database and ancillary database of the present invention can cooperate with multiple writers of data.

Referring again to FIG. 15, a flowchart for creating a new secondary database and an empty secondary database is shown. The suggestive context of FIG. 15 is one transaction running in a database or some other secondary database in a global database, and the owner or person in control of this transaction wants to create a new database. In FIG. 15, after initiation, step 482 creates a new DBCB. This database control block is created to have a control point or reference point at which a new secondary database is just created. As described above, in the preferred embodiment, there is no need to create a new copy of the data for the secondary database, but a copy can be made if desired. Steps 484, 486, and 488 relate to the DBCB created with other data structures that may exist. In step 484, the Own TX field of the DBCB is made with reference to the created or owned transaction. This step is performed to clarify the relationship between the generated transaction and the new DBCB. Not all steps of each flowchart are essential, but may be omitted if certain steps are desired or if they do not use their named data structures or fields, depending on the implementation used. Next, step 486 creates a super database field of the DBCB by referring to the appropriate super database of the DBCB. This is done to represent the system, or to clarify the DBCB data structure where some of the databases are new secondary databases. Step 488 refers to the sibling database, if any, by writing to the next DB field and the previous DB field in the DBCB data structure. This sibling database may be another secondary database previously created by the same creation transaction, and if so, such a relationship with another secondary database may be defined or created.

Then, in Fig. 15, in step 490, the appropriate information is recorded in the TCB of the generating transaction so that such DBCB is referred to by the Sub DB field of the TCB of the generating transaction. At this stage, the super database includes the new database in the set of secondary databases it has in its vehicle. Finally, at 492, a new lookup table for the LCBs is allocated, and this new lookup table is referenced from this DBCB. Note that this step 492 is not performed for all embodiments, but is preferred for the data structure of FIG. 11 and / or the data structure of FIG. 12. In the embodiment of Figures 11 and 12, each DBCB preferably has its own hash table, array or other lookup structure that is used as an entry point for assigning RIDs in its domain or secondary database. . The process of FIG. 15 then ends.

16 shows a process for taking an RID to a secondary database to populate that secondary database. The secondary database created in FIG. 15 will be emptied upon initial creation, and FIG. 16 shows how the object or data item is executed in the secondary database to make the object or data item available for future transactions to execute in the secondary database in question. Illustrated. In Fig. 16, after initiation, step 500 determines whether the operation in question is valid. This step is performed in the preferred embodiment because an object must be in a particular state without moving to a secondary database. For example, a transaction that is created and owns a secondary database is referenced to be owned by the object that it wishes to take to that secondary database at this point. Another query or test may be performed to pull one object into the secondary database only when it appears in the secondary database, whether or not the super database occurs in the global database or some other secondary database. Thus, in a preferred embodiment, one object can be pulled only from a direct super database at the database layer. If the operation is determined to be invalid, for example, the two states described above are not satisfied, so the process of Fig. 16 ends.

If it is determined at step 500 that the operation is valid, the process of FIG. 16 ends. The object in question can be imported into its secondary database. The embodiment of FIG. 16 relates to the data structure arrangement shown in FIGS. 2-4 and 6. Thus, step 502 locates the LCB for RID in the super database. This step is preferably performed to proceed to the hash table, hash the RID, obtain a hash table entry or reference, and then follow the pointer chain or reference from the hash table up to the LCB. The LCB will identify the RID in the global database. If the secondary database in which the object in question is currently being pooled has not some of the intermediate descendants of the global database, but has some other secondary database described above between the global database and itself, the resources of the intermediate super database of this secondary database. It is desirable to cross the next level database reference or next level LCB from one LCB to another until the LCB identifying them arrives. It can be seen that due to the tests performed on step 500, such LCB will be present.

After step 502, step 504 is performed to allocate a new LCB for the RID in question in this database or in a secondary database. This new LCB will represent the very same resource in this new secondary database that brings in the resources we created. In step 506, the LCB for this RID of the shooter database is made with reference to the new LCB. Finally, in step 508 the new LCB references the DBCB for this database. In other words, it clearly indicates a connection to the database, preferably by indicating that the new LCB is my database or my context database. The process of FIG. 16 then ends.

FIG. 17 is a flow chart illustrating a method of populating a database or an auxiliary database, but used for example for a change implementation with the data structures shown in FIGS. 11 and 12. An important purpose of this populating is to implement a lock structure by creating an LCB to determine the lock state of a resource. After initiation of FIG. 17, in step 510 it is determined whether the operation in question is valid. Since this step is the same step as that of Fig. 16, the description of this step is omitted. Next, in step 512, the DBCB for this database is located. At this time, a database such as a global database or some secondary database of interest is known. Preferably there is a database control block that represents a database attempting to pool to one object. Furthermore, preferably a method of locating the DBCB relative to the database is preferred, and may be executed to refer to a database control block. Next, step 514 assigns a new LCB (or SLCB) to the RID of the problem in this database. In this step, a new LCB is created by bringing a new object into the database. That is, if an object is in multiple databases, it will have as many CLBs as representing the object as there is a current database. Finally, in step 516 the LCB is inserted into the lookup table of the database. This can be done by hashing the record ID and obtaining a hash table entry assuming that the hash table is used, even if the array or table or the like is alternatively used as described above, and a new LCB must insert a hash function. Will be inserted into the hash table entry. If there is an empty chain of LCBs at this time (eg without CLBs), the LCB is inserted as the first item of the chain. If the chain is not empty, the LCB can be inserted into one of the first item or one of the other items in the chain, such as the last item or the middle item, while the entry is reachably inserted from the particular hash table or array entry in question. Can be inserted.

18 is a flow diagram illustrating exemplary steps of lock request processing using the data structure according to the embodiment of the present invention shown in FIGS. 2-4 and 6. In Figure 18, after startup, step 520 locates a hash table slot with respect to the RID in question. The lock request will identify a transaction requesting access to some data and will identify the RID or record ID of the data in question along the database where such RID will be found. Further, it will indicate an access mode, such as whether the data is desirable for reading or writing. This information is available to the lock manager when processing the lock request. Thus, to locate a hash table slot for a RID, there is a hash of the RID, a hash table entry is found, and a reference to that hash table entry is checked to determine whether there is an LCB for this RID in the global database. . If in step 522 it is determined that the LCB for RID is not present in the global database, the flow proceeds to step 530 to generate the LCB and insert it into the first level LCB chain. If in step 522 it is determined that the LCB for the RID does not exist in the global database, the lock request may be determined for the RID in the global database because there may be some error with the system, and in the non-existent secondary database It may be impossible to create a lock request for a data item. Thus, if the lock manager receives a lock request substantially, it can be assumed that this lock request is realistically matched in the arrangement of the data structure. Thus, if there is no LCB for the RID in the global database, then there is also no secondary database to which the data item in question belongs. Thus, if the answer to step 522 is "NO", then there is an alternative lock request on the resource or access to the resource of the query in the global database. This is a very simple situation, such as creating an LCB that does not exist, and since the LCB does not exist, it is easy to see that the requested lock will be granted unconditionally because there is no other transaction with a lock on that data item. Thus, insert the LCB into the first level LCB chain for the global database. Following step 530, step 532 grants the request and generates an LRB corresponding to the granted request.

Alternatively, if it is determined at step 522 that the LCB for the RID exists in the global database, then step 524 is performed to follow the "next level LCB" until the correct database or secondary database is found. In step 524, it can be executed 0 times, and even if there are requests for resources in the global database, it can be immediately known that the visible LCB is the desired or correct LCB, so that it can stop and not process another. have. Next, in step 526, it is determined whether a collision lock exists. This is easily determined by checking whether the request is compatible with an existing lock already granted on the data item. If at step 526 it is determined that there is a conflict lock, the process proceeds to step 528 where the request is waited or rejected. The system can be implemented such that there is a waiting period during which the lock manager wishes to release the current lock so that the lock manager can reconsider at some later point in time whether to grant the requested lock. Alternatively, step 528 may simply reject the requested lock and it is a matter of choice at design time about how to handle this problem. Rejecting the request halfway prevents you from waiting for any time you want to access the desired lock.

If there is no existing conflicting block at step 526, then proceed to step 532 to grant the request and generate an LRB for the request to properly indicate the lock of the resource or related data.

FIG. 19 illustrates a method of handling a lock request upon the appearance of a nested database as in FIG. 18, but relates to the data structures of FIGS. 11 and 12 in which every database or auxiliary database control block has its own lookup table. In Figure 19, after initiation, the LCB lookup table is located relative to the database at the time of query. This can be done by following the lookup table reference from the DBCB of the database identified by the lock request. Next, in step 536, a hash table slot for the RID is located if such a data structure exists for that embodiment. As an alternative to avoiding having a hash table, this embodiment may be implemented to more directly represent or assign LCBs. In a next step 538, it is determined whether the LCB for RID already exists. If the LCB does not exist, proceed to step 537 to determine whether there is a request for a resource in the global database. If LCB is present, proceed to step 544. However, if there is a request for a resource in some secondary database, but the LDB for that resource does not appear in the resource's lookup table, we face a special situation where the transaction is requesting something outside the scope of the context database. Normally, such a request can be rejected, which is indicated by the NO branch of step 539. However, the system can be programmed in such a way that the probability of dynamically calling the requested resource at this point and dynamically growing the secondary database at query time remains open, and in step 539 Determine whether to allow growth. Such determination may be made with or without human intervention. If the answer to step 539 is "YES", then step 544 is reached. If desired, the flowchart of FIG. 18 may be modified to insert between step 522 and step 530 of FIG. 19, in steps 537 and 539. This allows the function of steps 537 and 539 to be performed in the process of FIG.

In step 538, if there is already an LCB for the RID, then proceed to step 540 to determine if there is any conflict lock. If there is a conflict lock, the lock request is waited or rejected as described in step 528 of FIG. If there is no conflict lock, as described above, the lock request is granted and the process proceeds to step 546 where an LRB is created. The process of FIG. 19 then ends.

20 is a flowchart showing the steps performed during the termination of the secondary database. After activation, step 550 determines whether a particular transaction or secondary database of such a database exists. If the answer is " YES ", then proceed to step 552, asking whether or not you want to continue this process. The decision block of step 552 may be performed in any desired manner and may be determined manually by the user after consulting the user of the system if the user wishes to exit the secondary database. Alternatively, a voluntary decision may be made indicating whether to accept the termination of the secondary database. If there is a transaction or secondary transaction of such a database and wishes to maintain that secondary database, it proceeds from step 552, where the process ends if the data in question is desired to be maintained. Successive determinations of step 552 may be pre-programmed, computer program decisions may be made, or may be determined manually. If it is desired to exit at step 554, step 554 is executed such that all secondary databases and transactions of this database are terminated. This termination is another example of a recursion, because the operation of step 554 This is because the flowchart of FIG. 20 is executed again for the item ending in step 554.

If at step 550 it is determined that there is no transaction or secondary database for the database in question, or after performing step 554, step 556 performs reallocation of all LCBs to the database in question. This reassignment of step 556 can be performed safely, since there are no transactions or secondary databases that depend on these LCBs, and there are no LRBs, so they can be removed or reallocated (removed from the computer's memory). Next, in step 558, if a lookup table is used, the lookup table is reallocated. Note that in some examples, step 558 need not be performed because the lookup table may not be reassigned. Finally, in step 560, the DBCB is reallocated to the database in question, and when performing step 560, there is typically less memory structure in the computer memory dedicated to this secondary database, and the secondary database is Will not exist. The process of FIG. 20 ends.

In order to more easily understand the possible applications, results and features of the present invention, one example that the present invention may perform is shown in FIGS. 21A-21D. This example is an example of sharing a document, but the present invention can be used in a particular situation with more applications and wants to share data among multiple users. Moreover, the present invention can be used to share a portion of a document among users such that a plurality of users can be simultaneously worked on one document. For example, only one screen or computer display is shown per user, and each document or data item available to that user is shown on that screen. However, this is just one typical implementation, and in fact, it is not necessary for each data item in a query to be displayed on only one computer screen. Referring to FIG. 21A, Gail's computer screen 570 with four documents, namely Document 1 572, Document 2 574, Document 3 576, and Document 4 578, is shown. . In this screen 570 of FIG. 21A, Gale has record locked documents 1, 2, 3, 4, and can read and write the contents of these documents. As will be described later with respect to a data structure illustrating an implementation of the example of FIGS. 21A-21D, Gale has a top level transaction in a global database.

In FIG. 21B, Gail creates a secondary database, logically speaking, pooling documents (2, 3, 4) into this secondary database. This allows the documents to be read only as indicated by " R / O " in the upper right corner of each document.

In FIG. 21C, a screen slot 570 for Gale is shown, and also Brian has the ability to work on Document 2 582 and Document 4 584 as indicated on this screen 580. .

In FIG. 21C, Brian initiates a transaction in Gale's secondary database to record locked documents 2 and 4. Now, Brian has the ability to edit all of these documents, while Gale can't record the documents that he controls (2, 4) and, if desired, can read them and observe what Brian is doing. have.

In FIG. 21D, Gale's screen 570 and Brian's screen 580 are visible, but in addition, Anne shows a screen 590 showing Document 2 592 and Document 3 594, which are read-only documents. Have In the scenario of FIG. 21D, Ann starts a transaction at Gale's secondary database. The ann has a read lock on the document 2 and a write lock on the document 3, which can only be modified by the ann.

In FIG. 21D, it is noted that Brian has a write lock on document 2 582, while Anne has a read lock on document 2. In conventional systems, Brian's write lock and Anne's read lock can be normally compatible. In order for Anne to browse the work of Bryan, a parameterized lock or other mechanism can be used. Thus, the main focus of the present invention, namely the containment database, is coupled to parameterized locks, to achieve a system with yet another compatibility.

To implement the scenario present in the examples of FIGS. 21A and 21D, a typical data structure is shown in FIGS. 22A-22D and 23A-23D to illustrate how a secondary database and the sharing of that data may occur. 22A-22D show a first example of a data structure that can be used to implement the example of FIGS. 21A-21D. In FIG. 22A, Gail has a transaction control block (“TCB”) 600. There is also a lock control block (" LCB ") numbered 160-1 to 160-4, respectively. Lock request blocks (“LRBs”) 162-1 through 162-4 are used in conjunction with respective LCBs to implement locking of the document. Each LCB 160 of FIG. 22A is a global database 192. By referencing (actually a global database control block), it indicates that Gale has the highest level transaction in the global database. For Gale's best-level transaction TCB 600, there is full editing capability for each document 1-4. The LCB and its own data for these documents are either partial or related to the global database.

In FIG. 22B, which corresponds to FIG. 21B, Gail creates a secondary database and, logically speaking, moves documents 2, 3, and 4 to the secondary database. A secondary database can be created to invite others to whom Gail will cooperate with her. As Gail creates a secondary database, an additional data structure is shown in FIG. 22B. In particular, since the documents 2, 3, 4 are part of its secondary database, second level LCBs, also referred to as SLCBs, are generated for the documents 2, 3, 4, and reference numerals 164-. 2, 164-4, 164-1). It is shown that each of these SLCBs references Gail's secondary database control block (DBCB) 602. Since the document is not moved to her secondary database, there is no second level (LCB or SLCB) in Document 1. Thus, at this point, document 1 is only a document that Gail can edit, and other documents can only be browsed. In order for the data structures to indicate that Gail can only edit Document 1 so that other documents are moved to another secondary database, the mode fields of the LRBs for the documents moved to Gail's secondary database are displayed in relation to their locks. Can be modified to indicate capabilities associated with the. In Figure 22B, Gale's secondary database does not perform a transaction. Additionally, in FIG. 22B, the context database for Gale's TCB leaves a global database 192, and Gale's secondary database DBCB 602 indicates that Gale's secondary database is owned by Gale's transaction. See TCB 600. Referring to FIG. 22C, Brian starts one transaction in Gale's secondary database, and Brian's transaction is represented by Brian's TCB 604 on the upper right of FIG. In this particular example, Brian's transaction can only access documents 2, 3, 4 as a document in Gail's secondary database that Brian's transaction allows access to. However, by implementing the present invention, Gail can dynamically grow her database by adding more documents to the database after another transaction, such as Brian starting one transaction in a secondary database. In Fig. 22C, Brian places a record lock on the documents 2 and 4, and has all the editing capabilities for these documents. Thus, Gail knows what Brian is doing with the document, but can't directly overwrite Brian's changes. The ability of Brian to write lock on documents 2 and 4 is indicated by dashed arrows, and from Brian's TCB 604 to LRB 162-5 for Document 4, the LRB for Document 2 ( 162-6). Also shown in FIG. 22C is Brian's TCB 604, which references Gail's secondary database (or DBCB) 602, which indicates that the context database for Brian's TCB is Gale's database.

Referring to FIG. 22D, which corresponds to the deployment and access capabilities illustrated in FIG. 21D, Ann starts one transaction in Gale's secondary database. Like Brian's transaction, Anne's transaction will only access documents (2, 3, 4) unless Gale chooses to add more documents to her secondary database to grow her secondary database dynamically. Can be. At this time, Anne has a write lock on document 3 and a read lock on document 2. This information can be represented by the LRB 162-7 and the LRB 162-8. LRB 162-7 for SLCB for Document 2 will indicate a read lock and LRB 162-8 for Document 3 will have a mode set to indicate a write lock. At this point, Anne can only edit Document 3, but Brian can browse all the changes that are being made to Document 2. Ann may also browse document 4 if desired, and similarly, Brian may browse document 3 if desired. In addition to referring to LRBs 162-7 and 162-8, Anne's TCB 606 references Gail's secondary database 602 by contextual database reference.

23A-23D illustrate alternative implementations of performing the example of FIGS. 21A-21 using the data structure shown in FIG. 11. In FIG. 23A, corresponding to FIG. 21A, there are LCBs 160-1 through 160-4 for the four documents in question, each LCB referring to a corresponding LRB 152. Gail's TCB 650 refers to LRB 162, and Gale's TCB 650 references or indicates that the context database is a global database 192.

In FIG. 23B corresponding to FIG. 21B, Gail creates a secondary database, whereby a database control block 652 is generated for Gale's secondary database. Gale's secondary database 652 refers to Gale's TCB 650 indicating that Gale's secondary database is owned by Gale's transaction, and Gale's secondary database 652 also provides a hash table, array or other structure ( 654). This structure 654 has SLCBs 164-1, 164-2, and 164-3 for three documents that are part of Gale's secondary database. SLCB 164 is referenced by references 656, 658, and 660 of table 654.

In FIG. 23C corresponding to FIG. 21C, Brian's transaction occurs, represented by Brian's TCB 670 referring to Gale's secondary database control block 652, and is a context database or transaction of Brian's TCB 670. This is called Gale's secondary database 652. Brian obtains locks on documents 2 and 4 represented by LRBs 160-5 and 160-6, respectively.

In FIG. 23D corresponding to the arrangement of FIG. 21D, Ann's transaction occurs and has Gale's secondary database as its context database. This is represented by the context DB with reference to Anne's TCB 680, which refers to Gale's DBCB 652. In addition, Anne has certain rights in document 2,3, which is represented in the data structure by Anne's TCB 680, which references LRBs 160-7, 160-8 for document 2,3. Lose. The LRBs 160-7 and 160-8 will set their fields to indicate the read-only or write capability of the access that Ann has.

The foregoing examples described with respect to FIGS. 21A-23D include snoozing and sharing of other documents. However, the present invention is not limited to sharing one file or document level, but can be used to share only one file, document, engineering design, etc. among a plurality of users or entities. Achieving an implementation in which only one file, document, or other data item is shared within the framework of the implied database disclosed herein relates to the issue of lock granularity, that is, to any resources in which a lock data structure or LCBs appear. Thus, the present invention relies on extreme means of locking individual words, characters or bits. Moreover, outside of a document processing or word processing environment, other portions of the engineering drawings may be shared on a CAM / CAM system or any other system.

In the example shown in FIGS. 24A-24D (preferably, initial examples), Brian's transaction and Ann's transaction are actually secondary transactions of Gale's transaction. Thus, a false assumption would allow each transaction, ie Gale, Brian, and Anne, to be locked together with the same granularity as Gale's top-level transaction. As an alternative, however, it is easy to lock the Gale at that section level, and at the same time, it will be easy to have other independent top level transactions that are locked at the document or graph level. Although the concept of locks with multiple granularity is known, in accordance with the present invention, the concepts of multiple granularity locking and nested database may be used together, and these concepts may generally be considered to be orthogonal to each other (eg, independent of one another). have. Further information on multiparticulate locking is disclosed in the Anfindsen paper, which is referred to later.

Turning now to the example of FIGS. 24A-24D, FIG. 24A shows a typical screen image 710 of a Gale text editor. The text of the document in question has four sections, indicated by section 1, section 2, section 3, and section 4. In Fig. 24A, Gale has the illustrated section lock all sections and have complete editing capabilities for the entire document. In each section, sample text is described, but any desired text may be used.

In FIG. 24B, screen image 720 represents Gale's text editor, but within this image Gale has delegated sections (2, 3, 4) to the secondary database, and these sections are now read-only within her editor. Which is indicated diagonally in sections 2, 3 and 4.

In FIG. 24C, screen image 730 shows Brian's text editor. With respect to FIG. 24C, Brian accesses Gale's document through her secondary database (he was authorized to work by Gale). By successfully requesting the write lock on sections 2 and 4, they can edit in their editor, while sections 1 and 3 are read only. Note that the diagonal lines through the read-only section of the document are for illustrative purposes only and there is no need to draw the diagonal lines through the text. However, in the preferred embodiment, it can be seen that certain sections are preferably locked and other sections are not locked. This can be done by using different colored text, different kinds of background of the text, lock mode, or access capabilities. For example, color is assigned per person, and each section or other portion of the document will be colored according to the person or entity that has the write lock on the data. Alternatively, monochrome can be used to designate sections of the document that are read only.

Finally, in FIG. 24D, screen image 740 shows Anne's text editor. Anne accesses Gale's documents through her secondary database (she was delegated to work by Gale). Anne successfully requests a write lock on section 3, so she can edit it in her editor, while sections 1, 2 and 4 are read only.

The present invention may be suitably implemented using one or more conventional general-purpose digital computers programmed according to the teachings of the specification, as will be apparent to one of ordinary skill in the computer arts. Appropriate software coding can be readily made by experienced programmers based on the present teachings, as will be apparent to those skilled in the art. The invention may also be implemented by preparing an application specific integrated circuit or by connecting a suitable network of conventional component circuits, as will be apparent to one skilled in the art. Moreover, the present invention can be implemented using a plurality of computers, computing devices or other types of devices. Such devices may be connected via a particular type of network to connect data, commands, data requests, and other information related to the operation of the data management system. Such a computer network may preferably be implemented using a wired network and a wireless network such as a radio frequency, infrared or ultrasonic type network. Alternatively, in addition to using a general purpose computer or using a general purpose computer, the present invention is not limited to any type of personal digital assistant, including a palm pilot, an Internet service, a special purpose computer, and a particular type of internet browser including a telephone browser. It is planned to be implemented using the device.

The invention includes a computer program product, which is a storage medium containing instructions that can be used to program a computer to execute the process of the invention. This storage medium is a particular type suitable for storing electronic instructions including floppy disk, optical disk, CD-ROM, magnetic optical disk, ROM, RAM, EPROM, EEPROM, flash memory, magnetic card or optical card, or hard disk drive. It can include without being limited to the type of the disk containing the medium of the. The invention also includes a data structure described herein and may be stored in a memory or storage medium described herein.

While the present invention is described with reference to specific embodiments, those skilled in the art will recognize that various changes may be made and elements may be replaced equivalently without departing from the spirit and scope of the invention. For example, although the present invention has described a data structure stored in a memory, the data structures may be equally stored in a plurality of memories. Moreover, the present invention preferably contemplates combining data structures.

The present invention is made in the various publications based on the techniques and theories previously described by the inventors. These publications include "Apotram-an Application Oriented Transaction Mode", Doctor Scient Thesis, Ole Jorgen Anfindsen, 1997, "Supporting Cooperative Work in Multimeadia Conference by Means of Nested Database", Ole Jorgen Anfindsen, Proceedings of Norwegian Computer Science Conference -NIK'96, 1996, pp. 311-322, and "Cooperative Work Support in Engineering Environment by Means of Nested Databases", Ole Jorgen Anfindsen, Proceedings of CEEDA, 1996, Poole, UK, pp. 325-330, each of which is incorporated herein by reference in its entirety. Each publication and its description may be embodied or used by the present invention. In addition, US Pat. Nos. 5,983, 225 and 6,044,370 are incorporated by reference and may be used with or separately from the present invention.

Claims (72)

A memory for storing data for access by a data processing system, the memory comprising: A data structure containing transaction information, A data structure containing lock information of data of the transaction; A plurality of data structures containing information of a plurality of databases, At least one of the plurality of data structures, i.e., one database data structure, includes information of at least one of the transaction and the plurality of databases associated with the data. 2. The memory of claim 1 wherein the database data structure is associated with the data structure containing information of the transaction. 3. The memory of claim 2 wherein the database data structure includes a reference to the data structure that contains information of the transaction. 4. The memory of claim 3 wherein the reference to the data structure containing information of the transaction comprises a reference to a owning transaction. 5. The memory of claim 4 wherein the database data structure is a different data structure than the data structure containing information of the transaction. 2. The memory of claim 1 wherein the database data structure includes a field for storing an indication of at least one transaction that is active in the database. 2. The memory of claim 1 wherein the data structure containing information of the transaction includes a field indicating association with the database data structure. 8. The memory of claim 7, wherein the data structure that includes the information of the transaction includes a field indicating association with at least one secondary database of the transaction. 8. The memory of claim 7, wherein the field indicating relevance with the database data structure indicates relevance with a context database. 10. The memory of claim 9 wherein the field indicating association with the database data structure includes a reference to the database data structure. 12. The memory of claim 10 wherein the field indicating association with the database data structure includes a pointer to the database data structure. 12. The memory of claim 11 wherein the database data structure is a different data structure than the data structure containing information of the transaction. The memory of claim 1, wherein the data structure including information of the transaction includes a field indicating association with at least one secondary database. 2. The memory of claim 1 wherein the data structure that includes information of the transaction includes a field associated with the data structure that includes lock information. 15. The memory of claim 14 wherein the field associated with the data structure that includes lock information includes a reference to the data structure that includes the lock information. 16. The memory of claim 15 wherein the data structure comprising lock information comprises at least two separate data structures. 17. The memory of claim 16 wherein the two separate data structures comprise a lock control block and a lock request block. 18. The memory of claim 17 wherein a reference to the data structure that includes the lock information is a reference to the lock request block. 19. The memory of claim 18 wherein the lock request block includes a reference to another lock request block. 2. The memory of claim 1 wherein the data structure that includes lock information for data includes a field associated with the database data structure. 21. The memory of claim 20 wherein the field associated with the database data structure indicates which of the plurality of databases belongs to the lock. 22. The memory of claim 21 wherein the field associated with the database data structure includes a reference to the database data structure. 23. The memory of claim 22 wherein the field associated with the database data structure includes a pointer to the database data structure. 2. The memory of claim 1 wherein the data structure comprising lock information comprises at least two separate data structures. 25. The memory of claim 24 wherein the two separate data structures comprise a lock control block and a lock request block. 27. The memory of claim 25 wherein the lock request block includes a reference to another lock request block. 2. The memory of claim 1 wherein the data structure including lock information comprises a single data structure having at least one field for storing the permitted lock information. 28. The memory of claim 27 wherein the at least one field for storing the allowed lock information stores a bitmap for the allowed lock information. The memory of claim 1, wherein the data structure including lock information of the transaction data includes a field that associates the lock of data with another lock of data to another database. 30. The memory of claim 29 further comprising a data structure comprising different lock information for the other database referenced by the field that associates the lock of the data with another lock of the data for another database. 2. The memory of claim 1 wherein the data structure containing lock information of the data includes an indication of a database associated with the lock. 32. The memory of claim 31 wherein the data structure including lock information of the data comprises a reference to the data associated with the lock, wherein the reference is an indication of the database associated with the lock. 33. The memory of claim 32 wherein the reference to the database associated with the lock comprises a pointer. 2. The memory of claim 1, further comprising a data structure used for retrieval purposes and including information indicating relevance to the data structure including lock information of the data. 35. The memory of claim 34 wherein the data structure used for retrieval purposes includes a reference to the data structure that includes the relevant lock information. 36. The memory of claim 35 wherein the data structure used for retrieval purposes includes a pointer to the data structure that contains lock information that is the reference. 35. The memory of claim 34 wherein the data structure used for search purposes comprises a hash table. 35. The memory of claim 34 wherein the data structure used for search purposes comprises an array. 35. The memory of claim 34 wherein the data structure used for search purposes comprises a table. 35. The memory of claim 34 wherein the database data structure includes a reference to a data structure used for the search purpose. 41. The method of claim 40, further comprising: a second data structure used for a search purpose different from that used for the search purpose; And a second database data structure referencing a second data structure used for the search purpose. 35. The memory of claim 34 wherein the data structure used for the retrieval purpose includes the data structure including the lock information. 2. The memory of claim 1 wherein the data structure includes information of the transaction and the data structure and database data structure are included in the same layer. 44. The data structure of claim 43, further comprising: a data structure associated with a transaction that references a transaction and other data structures associated with the plurality of database structures; And a plurality of database structures referencing at least one data structure containing transaction information. The memory of claim 1, wherein the data structure includes information of a transaction, the data structure includes lock information of data of the transaction, and the database data structure is different from the data structure. A method of indicating that a data item is locked, the method comprising: Creating a data structure at a first hierarchy level indicating that the data item is locked by a first transaction associated with a first hierarchy level; Creating a data structure at a second hierarchy level indicating that the data item is locked by a second transaction associated with a second hierarchy level. 47. The method of claim 46, further comprising creating an association between a data structure created at the first hierarchical level and a data structure created at the second hierarchical level. 48. The method of claim 47, wherein the creating the association comprises generating a reference to a field of the data structure created at the first hierarchy level that references the data structure created at the second hierarchy level. . 47. The method of claim 46, wherein generating the data structure at the second hierarchical level includes generating the data structure at the second hierarchical level to include a reference to a database associated with the second hierarchical level. How. 50. The method of claim 49, wherein generating the data structure at the first hierarchical level comprises: at the first hierarchical level such that the data structure does not include a reference to a database associated with the second hierarchical level. Generating the data structure. 50. The method of claim 49, wherein generating the data structure at the first hierarchical level further comprises: configuring the data structure at the first hierarchical level such that the data structure includes relevance to a database associated with a first hierarchical level. Generating a method. A method of determining whether a lock exists on a data item, the method comprising: (a) determining whether a lock on the data item exists at a first hierarchical level; (b) if there is no lock on the data item in step (a), generating a lock on the data item at the first hierarchical level; (c) if it is determined in step (a) that there is no lock on the data item, determining whether there is a lock on the data item at a second hierarchical level; (d) generating a lock on the data item if there is no lock on the data item at the second hierarchical level. 53. The method of claim 52, wherein generating (b) comprises generating (b + 1) a data structure at a first hierarchical level indicating the lock. 54. The method of claim 53, wherein step (b) further comprises generating (b + 2) a reference from a search data structure to the data structure at the first hierarchical level indicating the lock. In a system indicating that a data item is locked, Means for creating a data structure at a first hierarchical level indicating that the data item is locked by a first transaction associated with a first hierarchical level; Means for generating a data structure at the second hierarchical level indicating that the data item is locked by a second transaction associated with the second hierarchical level. 56. The system of claim 55, further comprising creating a relationship between the data structure created at the first hierarchical level and the data structure generated at the second hierarchical level. 59. The system of claim 56, wherein said relationship generating means comprises means for generating a reference to a field of said data structure created at said first hierarchy level referencing said data structure created at said second hierarchy level. . 56. The apparatus of claim 55, wherein the means for generating the data structure at the second hierarchical level comprises means for generating the data structure at the second hierarchical level to include a reference to a database associated with the second hierarchical level. System. 59. The apparatus of claim 58, wherein the means for generating the data structure at the first hierarchical level comprises: at the first hierarchical level such that the data structure does not include a reference to a database associated with the second hierarchical level. Means for generating the data structure. 59. The apparatus of claim 58, wherein the means for generating the data structure at the first hierarchical level comprises: at the first hierarchical level the data structure comprises a relationship with a database associated with the first hierarchical level; And means for generating a data structure. A system for determining whether a lock exists on a data item, Means for determining whether a lock on the data item exists at a first hierarchical level; If the means for determining whether a lock on the data item exists at a first hierarchical level determines that no lock on the data item exists, generating a lock on the data item at the first hierarchical level. Sudan, If the means for determining whether a lock on the data item exists at the first hierarchical level determines that a lock on the data item exists at the second hierarchical level when the means for determining that no lock on the data item exists. Means for determining, Means for generating a lock on the data item if the lock on the data item does not exist at the second hierarchical level. 62. The system of claim 61, wherein the means for generating a lock on the data item at the first hierarchical level comprises means for generating a data structure at a first hierarchical level indicating the lock. 63. The apparatus of claim 62, wherein the means for generating a lock on the data item at the first hierarchical level comprises means for generating a reference from a search data structure to the data structure at the first hierarchical level indicating the lock. System. A computer program product having computer readable program code means for indicating that a data item is locked, Means for creating a data structure at a first hierarchical level indicating that the data item is locked by a first transaction associated with a first hierarchical level; And means for generating a data structure at a second hierarchy level indicating that the data item is locked by a second transaction associated with a second hierarchy level. 65. The computer program product of claim 64, further comprising creating a relationship between the data structure generated at the first hierarchical level and the data structure generated at the second hierarchical level. 66. The computer of claim 65 wherein the means for generating relationships comprises means for generating a reference to a field of the data structure created at the first hierarchical level that references the data structure created at the second hierarchical level. Program product. 65. The computer program product of claim 64, wherein the means for generating the data structure at the second hierarchical level comprises a reference to a database associated with the second hierarchical level. 68. The method of claim 67, wherein the means for generating the data structure at the first hierarchical level comprises: so that the data structure at the first hierarchical level does not include a reference to a database associated with the second hierarchical level. And means for generating the data structure in a table. 68. The apparatus of claim 67, wherein the means for generating the data structure at the first hierarchical level comprises the data at the first hierarchy such that the data structure at the first hierarchical level includes relevance to a database associated with the first hierarchical level. And means for generating a structure. A computer program product having computer readable program code means for determining whether a lock on a data item exists; Means for determining whether a lock on the data item exists at a first hierarchical level; Generating a lock on the data item at the first hierarchical level when the means for determining whether a lock on the data item is present at the first hierarchical level determines that no lock on the data item exists. Sudan, If the means for determining whether a lock on the data item is present at the first hierarchical level determines that a lock on the data item is present at the second hierarchical level, Means for determining whether or not, And means for generating a lock on the data item if a lock on the data item is not present at the second hierarchical level. 71. The apparatus of claim 70, wherein the means for generating a lock on the data item at the first hierarchical level comprises means for generating a reference from a search data structure to the data structure at the first hierarchical level indicating the lock. Computer program product. 72. The apparatus of claim 71, wherein the means for generating a lock on the data item at the first hierarchical level comprises means for generating a reference from a search data structure to the data structure at a first hierarchical level indicating the lock. Computer program product.