JPH06314225A - Transaction processing system - Google Patents

Abstract

PURPOSE:To provide a dynamic and flexible transaction processing system for a data base management system used in a design support environment. CONSTITUTION:When a slave transaction 104 and a transaction 102 are to share an object 114, a shared transaction 105 providing a shared object space is generated, and the object 114 being a shared target and an object 115 being a copy are caused to be held. Thus, the cooperative work of the slave transaction 104 and the transaction 102 is supported. Thus, the nesting hierarchy structure of the transaction can dynamically be reconstructed by permitting the respective transactions to execute cooperative work during execution. The parallel control protocol of the shared trasaction 105 can be designated at the time of generation.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a transaction processing system, and more particularly to a transaction processing for supporting collaborative work between a plurality of users in a database management system used in a design support environment such as CAD / CAM or CASE or groupware. It is related to the method.

[0002]

2. Description of the Related Art In a conventional transaction processing system of this kind, when supporting collaborative work between a plurality of users, a database management system is simply treated as a data storage (repository) to support collaborative work. A technique of preparing a dedicated program and controlling objects used by a plurality of user programs by using the dedicated program has been used. This technique requires frequent communication between the collaborative support program and the database management system to manage and control the objects shared between the user programs, and the user program must be shared by the collaborative support program. Since they are controlled collectively, the load concentrates there, and the processing throughput is reduced.

In recent years, a method for supporting cooperative work has been devised as a transaction management technique by a database management system. In the earliest of these, the database was separated into a shared database and a personal database, and the objects to be shared via the shared database using the check-in / check-out mechanism were fetched into each user's personal database. The collaborative work was realized by using it. However, in this method, since there is only distinction between sharing a database and individuals, there is no flexibility for interaction such as sharing of objects between users, and it is not possible to meet the requirements of various application programs.

Further, a recently proposed method is based on the nested transaction processing method. In this method, multiple transactions are nested in a hierarchical structure by executing subtransactions within a transaction. In the method that extends this method to support collaborative work, each transaction becomes a work area (workspace), and the upper transaction acts as a virtual database to realize a shared space of objects, and It supports the collaborative work of transactions.

An example of cooperative work according to this method will be described with reference to FIG. In this example, it is assumed that four objects 404 to 407 are stored in the database 400. A transaction 401 is a collaborative work space (parent transaction) for performing collaborative work. Now, in this collaborative work space, objects 405 and 407 in the database 400 are used as objects 408 and 409 (shared by a plurality of users). ing. Transactions 402 and 403 are transactions (child transactions) executed by different user programs participating in this cooperative work space. The child transactions 402 and 403 are combined by participating in the parent transaction 401 (a parent-child relationship is established). In order to use the objects 408 and 409, the child transactions 402 and 403 are taken out (checked out) from the parent transaction 401 and used as objects 410 and 412.

Here, in order to make the object 410 of the child transaction 402 available for other transactions, the information updated by the child transaction 402 to the object 408 of the parent transaction 401 is reflected (check-in). I will let you. Update object 408 to another child transaction 4
In order to be used by 03, the object is extracted and used as the object 411. In this way, objects can be shared and used among a plurality of users to support collaborative work.

[0007]

In the conventional transaction processing method described above, a shared space of objects can be realized in the transaction management device of the database management system, and cooperative work between users can be supported. , It is necessary to make a transaction, which is a shared space of objects for performing collaborative work, hierarchically in a nested structure from the upper level to the lower level. Therefore, in order to share an object with a transaction of another user program that is not under the same parent transaction, it is necessary to once reflect the update of all objects in the database and build a new transaction hierarchy. . These things cannot be done during the execution of a transaction, and work that spans multiple transactions is required.

Although not shown in FIG. 4, when an object is shared between transactions that are not siblings,
Each transaction cannot work on the same concurrency control protocol because they do not have a common parent transaction. In other words, the conventional transaction processing method that supports cooperative work is static, inflexible, and has the drawback that only limited cooperative work can be performed.

The object of the present invention is to eliminate the above drawbacks of the prior art by generating a shared transaction for transactions of a plurality of user programs which become a shared object space when performing collaborative work. A flexible transaction processing method that dynamically reconstructs the nested transaction hierarchy without interruption and allows each parent transaction to specify a protocol for concurrency control of objects used by the child transaction. To provide.

[0010]

The method of the present invention is an intermediate state of an object not reflected in a database in a transaction processing method of a database management system for the purpose of supporting cooperative work between a plurality of users. To share a transaction using a nested transaction hierarchy, to rebuild the hierarchy by manipulating a layered transaction at run time, and to recover the transaction in case of failure or cancellation of processing. It is characterized by including means for acquiring the history of transactions used in.

[0011]

In the present invention, the transactions for providing the shared space of the objects are created as their parent transactions between the transactions performing the cooperative work, so that the transactions which are not related to each other can be connected. . By doing this, a hierarchical structure is constructed from the lower level to the upper level, and it is not necessary to be aware of the nested transaction hierarchy for the shared space in advance. Further, since the parallel control protocol can be designated by each parent transaction, it is possible to deal with various application programs.

[0012]

Embodiments of the present invention will now be described with reference to FIGS.

FIG. 1 is a transaction hierarchy diagram showing an embodiment of the present invention. As an initial state in this example, four objects 106 to 10 are stored in the database 100.
9 is present. Transaction 101
Object 106, 107 to object 110,
111, and the transaction 102 uses the object 109 as the object 112.

FIG. 3 is a block diagram showing an example of the configuration of the present invention. The transaction processing device 300 includes a transaction operation unit 301, a nested structure management unit 302, a concurrency control protocol management unit 303, and a history management unit 304. A request for transaction processing is accepted by the transaction operation unit 301. Also,
A protocol for parallel control of transactions is managed by the parallel control protocol management unit 303.

The transaction operation unit 301 receives a request from a user program and operates a corresponding transaction, and the nested structure management unit 302 manages a nested transaction hierarchy. Further, the concurrent control protocol management unit 303 manages a plurality of protocols to provide various concurrent control protocols for child transactions, and the history management unit 304 recovers (recovers).
Keep history for. Then, the transaction operation unit 301 and the nested structure management unit 302 dynamically reconstruct the nested transaction hierarchy, and the transaction operation unit 301 and the concurrency control protocol management unit 30.
3 controls each nested transaction hierarchy by a different kind of concurrent control protocol.

FIG. 2 is a flow chart showing an operation of transaction hierarchy reconstruction carried out in the transaction processing apparatus shown in FIG. 3 when a user program operates a transaction for cooperative work.

In the following, the operation of processing a transaction hierarchy reconstruction request from a transaction in a user program to a transaction processing device will be described in detail with reference to FIGS. 1 and 3 according to the flow chart of FIG. explain.

When the transaction 101 is divided into child transactions 103 and 104 for cooperative work, first, the transaction 101 issues a transaction division request to the transaction processing device 300 (200). This request is accepted by the transaction operation unit 301, where the child transactions 103 and 104 are created, and the parent-child relationship information of the newly created transaction is stored in the nested structure management unit 302 (201).

The child transactions 103 and 10
4 required objects (110, 11 respectively)
1) is copied (the actual copy is performed by an object management device (not shown) in the database management system. The same applies to the following copy operation), and the object 11
It is made available as 3, 114 (202). The usage information of this object is stored in the history management unit 304 for object update control, similar to the acquisition of the object from the database 100. The generated child transactions 103 and 104 are respectively combined with the user program and can continue processing in parallel with each other.

On the other hand, in order for the transaction 102 to share and use the object 114 in 104, the transaction 102 first sends the transaction 1 to the transaction processing device 300.
A sharing request with 04 is issued (203). This request is accepted by the transaction operation unit 301, a shared transaction 105 that is a shared space of the objects of both transactions is generated, and the parent-child relationship information of the generated or changed transaction is stored in the nested structure management unit 302 (204). .

Then, the shared object 114 is copied as the object 115 in the shared transaction 105 so that it can be used in both transactions (205). Further, the object 115 shared by the transaction 102 which issued the sharing request is copied as an object 116 so that it can be used (206). Usage information of this object is stored in the history management unit 304.

When the transaction operation unit 301 receives a request other than the above, such as a database open / close request or an object lock request, other processing is executed (207).

The final transaction hierarchical structure is shown in FIG. The parents of the transactions 104 and 102 are the shared transaction 105, and the parent of the shared transaction 105 is the transaction 101. If the shared transaction 105 commits, then FIG.
Transaction 1 which is its parent, as indicated by the dotted line in
It will be reflected in 01 (124).

The transaction on each layer is controlled by the concurrency control protocol specified by the parent transaction. This protocol is managed by the parallel control protocol management unit 303, and a protocol satisfying a plurality of correctness standards is prepared. When a transaction requests acquisition of an object, the transaction operation unit 301 performs exclusive control of the requested object through the parallel control protocol management unit 303.

[0025]

According to the present invention, the nested hierarchical structure of transactions can be dynamically reconstructed for cooperative work between a plurality of users, and it is not necessary to determine the hierarchical structure of each transaction in advance. . In addition, since a protocol for parallel control of objects used by child transactions can be set for each transaction, it is expected that the requirements of application programs can be flexibly satisfied.

[Brief description of drawings]

FIG. 1 is a transaction hierarchy diagram showing an embodiment of the present invention.

FIG. 2 is a flowchart explaining the operation of the present invention.

FIG. 3 is a block diagram showing a configuration example of the present invention.

FIG. 4 is a transaction hierarchy diagram of a conventional transaction processing method that supports cooperative work.

[Explanation of symbols]

100,400 database 101,102 transaction 103,104,402,403 child transaction 105 shared transaction 106-116,404-412 object 300 transaction processing device 301 transaction operation unit 302 nested structure management unit 303 concurrency control protocol management unit 304 history management Department 401 Parent transaction

Claims (2)

[Claims] 1. In a transaction processing method of a database management system for the purpose of supporting collaborative work between multiple users, an intermediate state of an object not reflected in the database is shared by using a nested transaction hierarchy. Means for reconstructing the hierarchy by manipulating the layered transaction at run time, and for acquiring the history of transactions used for transaction recovery in the event of failure or cancellation of processing. A transaction processing method comprising means. 2. Within the nested transaction hierarchy,
2. The transaction processing method according to claim 1, wherein a plurality of protocols for controlling the sibling transactions in parallel are prepared and managed in the transaction processing device.