JP7031919B1 - Transaction processing system and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a transaction processing system and a method for maintaining the integrity of a plurality of snapshots for a plurality of transactions. A transaction processing system 20 includes a plurality of sub-application units and a plurality of CC-OCC transaction managers provided in a plurality of data source client systems. For each transaction, N CC-OCCs receive object read requests and / or write requests from two or more sub-application units in the processing of the M sub-transactions that make up the transaction (M is an integer of 2 or more). In the case of (N is an integer of 2 or more), the union of N pieces is a pairwise transaction. For each of the N unions, the union is the union of the readset and writeset in the snapshot managed by CC-OCC corresponding to the transaction. [Selection diagram] Fig. 3

Description

The present invention generally relates to the processing of transactions.

Generally, transactions are processed in the execution of business logic that realizes a service. A transaction is generally a collection of operations that are processed atomically and, for example, consists of multiple CRUD (Create, Read, Update or Delete) requests. In transaction processing, it is necessary to process CRUD requests while guaranteeing ACID (Atomicity, Consistency, Isolation and Durability) properties for a plurality of objects.

In transaction processing, a data source server system having a plurality of objects (for example, a plurality of records) is read and / or written by the data source client system, which is a client system for the data source server system.

As transaction processing, transaction processing including OCC (Optimistic Concurrency Control) is known (for example, Non-Patent Document 1). In OCC, validation is performed based on the snapshot at the time of commit. Snapshots exist for each transaction. For each transaction, the snapshot contains a readset, which is a set of zero or more read objects, and a writeset, which is a set of zero or more write objects. For each transaction, the lead object is the object that was read in the processing of that transaction. For each transaction, a write set is an object that is lighted in the processing of that transaction.

HT KUNG and JOHN T. ROBINSON. On Optimistic Methods forConcurrency Control. ACM Transactions on Database Systems, Vol. 6, No. 2, June 1981, Pages 213-226. (Https://citeseerx.ist.psu.edu/viewdoc /summary?doi=10.1.1.101.8988)

Business logic is generally executed by the application department. The application unit is software (typically an application program) (or a function realized by executing the software). The application unit sends a request for reading and / or writing an object to the Tx (transaction) manager in the processing of the transaction.

It is known to divide a business logic (for example, a service) into a plurality of sub-business logics (for example, a plurality of microservices), in other words, to construct one business logic from a plurality of sub-business logics. In this case, a plurality of sub-application parts that execute a plurality of sub-business logics are designed.

When an architecture including a plurality of sub-application parts is adopted in this way, a plurality of sub-transactions constituting one transaction are processed.

Further, when a plurality of Tx managers are provided in a plurality of data source client systems, each Tx manager is used as a client-coordinated Tx manager for the reason that the transaction function is realized in the data source client system having no transaction function. Is conceivable. Hereinafter, the client-coordinated Tx manager that performs OCC is referred to as "CC-OCC". Each of the plurality of CC-OCCs manages snapshots for each transaction. In addition, in this specification, "the Tx manager is a Client-coordinated Tx manager" means that the Tx manager generally arranged in the data source server system is arranged not in the data source server system but in the data source client system. Moreover, information is not exchanged between Tx managers arranged in the data source client system by communication or the like. Further, CC-OCC "manages snapshots" means that the snapshot is stored in the data source client system having the CC-OCC (for example, the memory of the data source client system), and the snapshot. May be inside or outside the CC-OCC.

In an architecture that includes multiple sub-application parts and multiple CC-OCCs in multiple data source client systems, maintaining the integrity of multiple snapshots when processing multiple transactions in parallel is not possible. ,Have difficulty. Hereinafter, an example thereof will be described with reference to FIGS. 1A to 2B. In the explanation, the premise and terms (hereinafter referred to as "glossary" for convenience) are as follows. Further, the sub-application part may be provided inside or outside the data source client system.
-The service is a service that "when the total of a plurality of points in a plurality of member accounts belonging to a family account exceeds a predetermined value, a predetermined point is given to each of the plurality of member accounts".
-Member accounts A and B are a plurality of member accounts belonging to a certain family account. Member accounts C and D are a plurality of member accounts belonging to different family accounts.
-Points in a plurality of member accounts are recorded in DBs (databases) 521A and 521B in a server system 15 (an example of a data source system) (note that DB 521 may be one or three or more).
-Record X (X = A, B, C or D) is one record in which points in the member account X are recorded.
-Lead X is the lead of record X.
-Light X is the light of record X.
-Read record X: A record X read by the lead X, which is a record included in the read set in the snapshot.
-Light record X: A record X that is lighted by the light X and is a record included in the light set in the snapshot.
Tx1 is composed of leads A to D and writes A to D. For each of write A and B in Tx1, when the total of points recorded in member accounts A and B (records A and B read by leads A and B) belonging to the same family account exceeds a predetermined value. It is performed to add a predetermined point to (the same applies to each of the lights C and D in Tx1).
-DB is an abbreviation for database and is an example of a data source.

As illustrated in FIG. 1A, the DB client system 531 has an application unit 518 and a Tx manager 519, and the Tx manager 519 accesses DB 521A and 521B. In the architecture in which one application unit 518 in the DB client system 531 executes one business logic, it is easy to maintain the integrity of the snapshot 5 managed by the Tx manager 519 that performs OCC. For example, as shown in FIG. 1B, when the read B and the write B of the Tx2 are performed before the write B of the Tx1, the Tx manager 519 can detect that the consistency of the snapshot 5 is broken, and therefore, You can abort Tx1.

However, as illustrated in FIG. 2A, in an architecture in which the DB client systems 531A and 531B include sub-application units 418A and 418B and CC-OCC419A and 419B, snapshots 5A and CC-OCC419B managed by CC-OCC419A It is difficult to maintain the integrity of the managed snapshot 5B. For example, in the architecture illustrated in FIG. 2A, it is assumed that the transaction isolation level is the isolation level in which Read-skew anomaly occurs in addition to Write-skew anomaly and Read-only anomaly of Snapshot Isolation. Further, as shown in FIG. 2B, it is assumed that Tx1 is divided into two sub-transactions (Tx1 _Sub1 and Tx1 _Sub2 ). It is assumed that the Tx1 _Sub1 is composed of the leads A to D, the write A and the write C, and the Tx1 _Sub2 is composed of the leads A to D, the write B and the write D. It is assumed that the sub-application unit 418A first processes Tx1 _Sub1 and then the sub-application unit 418B processes Tx2 and then Tx1 _Sub2 . In this case, since the record B is updated by the write B of Tx2, a read skew that the record B read by the read B of Tx1 _Sub2 is newer than the record B read by the read B of Tx1 _{Sub 1} occurs. However, in the architecture where Client coordinated is adopted, neither CC-OCC421A nor CC-OCC421B can detect the occurrence of read skew, and therefore record B is inconsistent between snapshots 5A and 5B. Instead, both Tx1 _Sub1 and Tx1 _Sub2 are committed.

The transaction processing system includes a plurality of sub-application units that execute a plurality of sub-business logics constituting the business logic that realizes the service, and a plurality of CC-OCCs. A plurality of CC-OCCs are provided in a plurality of data source client systems. A plurality of data source client systems is a plurality of client systems for a data source server system having a plurality of objects. A data source server system and a plurality of data source client systems are one or more computer systems. Each object is data representing the state of the target.

Each of the plurality of sub-application parts is in charge of the read request and / or write request of the object to be read and / or written in the execution of the sub-business logic, in the data source client system having the sub-application part. Send to CC-OCC.

Each of the plurality of CC-OCCs is a CC (Client Coordinated) transaction manager that performs OCC (Optimistic Concurrency Control). Each of the plurality of CC-OCCs manages snapshots for each transaction.

For each transaction, a snapshot of that transaction includes a readset, which is a set of zero or more read objects, and a writeset, which is a set of zero or more write objects. A read object is an object that has been read in response to an object's read request. A light object is an object that is lit in response to the object's light request.

For each transaction, N CC-OCCs receive object read requests and / or write requests from two or more sub-application units in the processing of the M sub-transactions that make up the transaction (M is an integer of 2 or more). In the case of CC-OCC (N is an integer of 2 or more), the union of N is a pairwise transaction. For each of the N unions, the union is the union of the readset and writeset in the snapshot managed by CC-OCC corresponding to the transaction. For each of the M sub-transactions, the sub-transaction is processed in the execution of the sub-business logic and includes a read request and / or a write request for the object from the sub-application part to the CC-OCC.

Maintain the integrity of multiple snapshots managed by multiple CC-OCCs for each transaction in an architecture that includes multiple sub-application parts and multiple CC-OCCs in multiple data source client systems. be able to.

The architecture according to the first comparative example is shown. The flow of Tx1 and Tx2 in the first comparative example is shown. The architecture according to the second comparative example is shown. The flow of Tx1 and Tx2 in the second comparative example is shown. An example of the outline of the embodiment is shown. An example of the configuration of the entire system according to the embodiment is shown. An example of the configuration of the DB client system and the DB server system is shown. A configuration example of the mapping table is shown. A part of an example of the processing flow of Tx1 is shown. A part of an example of the processing flow of Tx1 is shown. A part of an example of the processing flow of Tx1 is shown. A part of an example of the processing flow of Tx1 is shown. A part of an example of the processing flow of Tx1 is shown. A part of an example of the processing flow of Tx1 is shown. An example of the relationship between the sub-application part and CC-OCC is shown. An example of the relationship between the sub-application part and CC-OCC is shown.

In the following description, an "interface device" includes one or more interfaces. The one or more interfaces may be one or more homogeneous communication interface devices (eg, one or more NICs (Network Interface Cards)) or two or more heterogeneous communication interface devices (eg, NICs and HBAs). It may be Host Bus Adapter)).

Also, in the following description, the "storage device" includes one or more memories. At least one memory with respect to the storage device may be a volatile memory. The storage device is mainly used for processing by the processor. In addition to the memory, the storage device may include one or more non-volatile storage devices (for example, HDD (Hard Disk Drive) or SSD (Solid State Drive)).

Also, in the following description, "processor" includes one or more processors. The at least one processor is typically a microprocessor such as a CPU (Central Processing Unit). Each of the one or more processors may be single-core or multi-core. The processor may include hardware circuits that perform some or all of the processing.

Further, in the following description, the process may be described with "program" as the subject, but the program is executed by the processor to appropriately perform the specified process in the storage device (for example, memory) and / or. Since it is performed while using an interface device (for example, a communication port), the subject of processing may be a processor. The process described with the program as the subject may be a process performed by a processor or a device having the processor. Further, the processor may include a hardware circuit (for example, FPGA (Field-Programmable Gate Array) or ASIC (Application Specific Integrated Circuit)) that performs a part or all of the processing. The program may be installed from the program source into a device such as a calculator. The program source may be, for example, a program distribution server or a computer-readable recording medium (eg, a non-temporary recording medium). Further, in the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

Further, in the following description, the function may be described by the expression of "yy part", but the function may be realized by executing one or more computer programs by the processor, or one. It may be realized by the above hardware circuit (for example, FPGA or ASIC), or may be realized by a combination thereof. When the function is realized by executing the program by the processor, the specified processing is appropriately performed by using the storage device and / or the interface device, so that the function may be at least a part of the processor. good. The process described with the function as the subject may be a process performed by a processor or a device having the processor.

Further, in the following description, the common code among the reference codes may be used when the same type of elements are not distinguished, and the reference code may be used when the same type of elements are distinguished.

Further, in the following description, a "record" is a block of logical electronic data seen from a program such as an application program, and specifically, an example of an object which is data representing a target state. Is. The data as a record may be, for example, a key-value pair or a tuple.

Further, the "object" is an arbitrary tangible or intangible object. For example, an account can be adopted as the "target" and points in the account can be adopted as the target state.

Further, "read and / or write" means one or both of read and write, and may be generically referred to as "read / write access". Similarly, "read request and / or write request" means one or both of read request and write request, and may be collectively referred to as "read / write access request".

Hereinafter, an embodiment of the present invention will be described. In the following description, the above-mentioned glossary used in the description of FIGS. 1A to 2B is adopted.

FIG. 3 shows an example of an outline of an embodiment.

For the DB server system 15 having one or more DB 521 (for example, DB 521A and 521B), there are a plurality of DB client systems 13 (for example, DB client systems 13A and 13B). One or more DB 521 is an example of a data source, a DB server system 15 is an example of a data source server system, and a DB client system 13 is an example of a data source client system.

The transaction processing system 20 includes a plurality of sub-application units 18 and a plurality of CC-OCC 19. At least a plurality of CC-OCC19s among the plurality of sub-application units 18 and the plurality of CC-OCC19s are provided in the plurality of DB client systems 13.

A plurality of sub-business logics constituting the business logic are executed by the plurality of sub-application units 18. Multiple sub-business logics may be determined from any point of view. For example, if the business logic consists of order processing and settlement processing, multiple sub-business logics may have different functions such as sub-business logic as order processing and sub-business logic as settlement processing. Alternatively, it may be a sub-business logic that performs order processing and settlement processing but has a different accessible record range. A plurality of sub-business logics may be predefined (for example, the sub-business logic may be defined in advance in the sub-application unit 18), or a plurality of sub-business logics may be dynamically defined from the business logic (for example). It may be generated (by the coordinator 16 described later).

Since CC-OCC19 is a client-coordinated Tx manager, communication between CC-OCC19 is not performed. Therefore, each sub-application unit 18 is provided with a function of communicating between the sub-application units 18. For the sake of simplicity, it is assumed that one CC-OCC19 exists in one sub-application unit 18, and those sub-application units 18 and CC-OCC19 are provided in one DB client system 13. The code of CC-OCC19 of the sub-application unit 18 is set to "19S". The CC-OCC19S is a CC-OCC that accepts a record read request and / or a write request in transaction processing (processing of a plurality of sub-transactions constituting the transaction). For each transaction, the CC-OCC19S manages the snapshot 10 (read set and write set) (for example, stored in the memory of the DB client system 13). A read set is a set of 0 or more read records. A read record is a read record in memory. A light set is a set of 0 or more light records. A write record is a record that is written in memory.

In addition, a transaction coordinator 16 is provided. The coordinator 16 performs transaction start, preparation processing, commit processing, rollback processing, and the like. As will be described later, the coordinator 16 may send a sub-business logic execution request to the sub-application unit 18 (the sub-business logic execution request is transmitted to the sub-application unit 18 by another sub-application unit 18). May be broken). The coordinator 16 may exist for each transaction, or may be common to a plurality of transactions. The coordinator 16 may be present in or outside the at least one sub-application unit 18. The coordinator 16 may exist in the DB client system 13 or may exist outside the DB client system 13. For the sake of simplicity, it is assumed that one coordinator 16 common to a plurality of transactions exists outside the sub-application unit 18, and one CC-OCC19 exists in one coordinator 16. The code of CC-OCC19 of the coordinator 16 is set to "19C". It is assumed that the coordinator 16 and CC-OCC19C exist in the DB client system 13A.

A transaction is composed of a plurality of operations and is processed atomically by a Tx manager (CC-OCC19S in this embodiment). A transaction consists of multiple sub-transactions, in other words, the transaction is divided into multiple sub-transactions. The sub-transaction includes a record read request and / or a write request from the sub-application unit 18 to the CC-OCC19S. The CC-OCC that has received the read request and / or write request for the record writes the record from DB 521 to read and / or DB 521.

In the execution of multiple sub-business logics that make up business logic, multiple sub-transactions that make up a transaction are processed. It is assumed that the plurality of sub-transactions are M sub-transactions (M is an integer of 2 or more). Further, the CC-OCC19S that receives a record read request and / or a write request from two or more sub-application units 18 in the processing of the plurality of sub-transactions is N CC-OCC19S (N is an integer of 2 or more). Suppose there is. For the sake of simplicity, in this embodiment, M = N, and therefore, it is assumed that the sub-transaction and CC-OCC19S have a 1: 1 correspondence. The sub-business logic is transmitted to the sub-application unit 18 by the coordinator 16, and the sub-transaction is processed by the sub-application unit 18.

In this embodiment, the following invariant expression is satisfied for each transaction.

In the invariant, N is the number of sub-transactions. i is a serial number (for example, ID) of the sub-transaction. RS _i is a read set of sub-transaction i. WS _i is a write set of sub-transactions i.

Therefore, this invariant means that "the union of the read set and write set for each sub-transaction that constitutes a transaction is relatively disjoint for all the sub-transactions that make up the transaction." .. For example, suppose there is a service and Tx1 described with reference to FIG. 2B as a service and a transaction. In this case, since the sub-transaction and CC-OCC19S are 1: 1 in the present embodiment, as shown in FIG. 3, there are two sub-transactions constituting Tx1. Then, the union corresponding to the two subtransactions (the union of RS _i and WS _i (i = 1, 2)) must be a pairwise disjoint. Therefore, Tx1 is divided into Tx1 _Sub1 (lead A, read B, write A and write B) and Tx1 _Sub2 (lead C, read D, write C and write D). Tx1 _Sub1 is assigned to CC-OCC19SA and Tx1 _Sub2 is assigned to CC-OCC19SB. As a result, the invariant, that is, the union in snapshot 10A of CC-OCC19SA (union of RS ₁ and WS ₁ ) and the union in snapshot 10B of CC-OCC19SB (union of RS ₂ and WS ₂ ). It is maintained that and is a pairwise disjoint. Note that the method of maintaining the invariant is not limited to such transaction division and sub-transaction allocation. An example of how to maintain an invariant will be given later.

Further, this invariant may be satisfied for each transaction as described above. In other words, the union of readsets and writesets does not have to be pairwise disjoint between transactions. For example, for Tx1, if read record A or write record A is included in snapshot 10A of CC-OCC19SA, record A must not be included in snapshot 10B of CC-OCC19SB, but is separate from Tx1. For Tx2, which is Tx, record A may be included in snapshot 10B of CC-OCC19SB (in this case, for Tx2, record A may not be included in snapshot 10A of CC-OCC19SA). ).

Since the above invariant expression is satisfied for each transaction, in an architecture including a plurality of sub-application units 18 and a plurality of CC-OCC19S provided in a plurality of DB client systems 13, a plurality of CC-OCC19S are used for each transaction. The integrity of a plurality of managed snapshots 10 can be maintained.

Hereinafter, the present embodiment will be described in detail.

FIG. 4 shows an example of the configuration of the entire system according to the present embodiment.

The plurality of DB client systems 13A, 13B, ... And the DB server system 15 are communicably connected via the communication network 19.

Any configuration may be adopted as the configuration of the DB client system 13.

For example, the DB client system 13A may be a client system having a user program 124 in addition to the sub-application unit 18A, CC-OCC19SA, coordinator 16 and CC-OCC19C. Further, the DB client system 13B may be a DB client system connected to the user system 12 that executes the user program 124 via the communication network 14. The user system 12 may be a user's computer (for example, a personal computer). The user program 124 may be a Web browser or an application program. The communication network 14 may be integrated with the communication network 19.

The DB client system 13 is a client system for the DB server system 15, but may be a server system for the user system 12. The DB client system 13 may be a client system (end client) in the entire system.

Further, the sub-application unit 18 may exist in a system (for example, a user system 12) external to the DB client system 13. Further, the sub-application unit 18 may function as a server application or a desktop application. Further, the sub-application unit 18 may be provided to a system such as the DB client system 13 or the user system 12 via the network.

The DB server system 15 has a plurality of (or one) DBs 21 and a DB manager 20 that inputs / outputs data to / from the DB 21 in response to a request from the CC-OCC19S.

The DB server system 15 and the plurality of DB client systems 13 are one or a plurality of computer systems. For example, the DB server system 15 and the DB client system 13 may be separate computer systems or one common computer system.

FIG. 5 shows an example of the configuration of the DB client system 13 and the DB server system 15.

The DB client system 13 includes one or more DB client computers 130. Since the DB client computer 130 included in the DB client system 13 may be one, one DB client computer 130 may be one DB client system 13.

The DB client computer 130 has an interface device 131, a storage device 132 (including a memory), and a processor 133 connected to them.

The interface device 131 is connected to the communication network 19.

The storage device 132 stores the sub-service program 180 and the CC-OCC program 190 (and the coordinator program 160). When these are executed by the processor 133, the sub-application unit 18 and the CC-OCC19 (and the coordinator 16) are realized. Further, the storage device 132 stores the mapping table 201, which will be described later.

The DB server system 15 includes one or more DB server computers 150. Since the DB server computer 150 included in the DB server system 15 may be one, one DB server computer 150 may be the DB server system 15.

The DB server computer 150 includes an interface device 151, a storage device 152, and a processor 153 connected to them.

The interface device 151 is connected to the communication network 19.

The storage device 152 stores the DB manager program 200. When this is executed by the processor 153, the DB manager 200 is realized. Further, the storage device 152 stores the DB 521.

FIG. 6 shows a configuration example of the mapping table 201.

The mapping table 201 is a table stored in each DB client system 13 and referenced by the sub-application unit 18. The mapping table 201 may exist for each sub-application unit 18 or for each CC-OCC19S. Further, in each DB client system 13, the mapping table 201 may exist for each transaction or may be common to all transactions. Further, the mapping table 201 may be prepared in advance, or may be dynamically generated by, for example, the coordinator 16. In the present embodiment, it is assumed that the mapping table 201 is prepared in advance for each transaction for each sub-application unit 18.

The mapping table 201 represents which CC-OCC19S of which sub-application unit 18 reads and / or writes which record, that is, the correspondence between the record, the responsible CC-OCC19S, and the sub-application unit 18. For each record, the "in charge CC-OCC19S" is the CC-OCC19S in charge of reading and / or writing the record (reading and / or writing of the record is permitted). For example, the mapping table 201 includes the ID of the CC-OCC19S for each CC-OCC19S, the ID of the sub-application unit 18 capable of transmitting a record read request and / or a write request to the CC-OCC19S, and the CC-. The OCC19S represents the ID of the record that can be read and written as the CC-OCC19S in charge.

As described above, in the present embodiment, the sub-transaction and the CC-OCC19S correspond 1: 1 for each transaction, and there is one CC-OCC19S for each sub-application unit 18. Then, in the mapping table 201, the record IDs are not duplicated between the sub-application units 18 (between CC and OCC19S). As a result, the above-mentioned invariant is maintained. As described above, if the transactions are different, the record IDs may be duplicated between the sub-application units 18 (between CC and OCC19S). For example, the sub-application unit 18A (CC-OCC19SA) reads and / or writes the record with the record ID “001” in one transaction, and the sub-application unit 18B (CC-OCC19SB) reads and / or reads the record in another transaction. You may light it.

Hereinafter, an example of Tx1 processing will be described with reference to FIGS. 7 to 11. Tx1 is an example of a transaction, and Tx1 _Sub1 and Tx1 _Sub2 constituting Tx1 are examples of a plurality of sub-transactions constituting the transaction. BL1 is an example of business logic, and BL1 _Sub1 and BL1 _Sub2 constituting BL1 are examples of a plurality of sub-business logics constituting business logic. Hereinafter, for the sake of simplicity, it is assumed that the sub-business logic and the sub-transaction have a 1: 1 relationship.

As shown in FIG. 7, the coordinator 16 causes CC-OCC19C to start Tx1 (S701).

BL1 _Sub1 starts. Specifically, the coordinator 16 requests the sub-application unit 18A to execute BL1 _Sub1 (S702). BL1 _Sub1 may be defined in advance in the sub-application unit 18A, or may be associated with a request dynamically generated by the coordinator 16 and transmitted in S702.

The sub-application unit 18A receives the execution request of BL1 _Sub1 (S703). S704 to S711 are performed for all read records (all records to be read) specified in BL1 _Sub1 . Take one lead record as an example.

The sub-application unit 18A refers to the mapping table 201 (mapping table 201 corresponding to Tx1) of the sub-application unit 18A (S704), and whether or not its own ID corresponds to the ID of the read record (in charge of the read record). Whether or not the sub-application unit 18 that can access the CC-OCC19S is the sub-application unit 18A) is determined (S705). When the determination result of S705 is true, the sub-application unit 18A requests the CC-OCC19SA to read the read record, the CC-OCC19SA reads the record in response to the request, and the read record is stored in the DB. It is stored in the memory of the client system 13A (S706). The read record is included in RS ₁ in the snapshot (Tx1 snapshot) managed by CC-OCC19SA.

If the determination result of S705 is false, the sub-application unit 18A is the sub-application unit 18B corresponding to the ID of the read record (the sub-application unit 18 specified from the mapping table 201, and the CC-OCC19S in charge of the read record is used. The accessible sub-application unit 18B) is requested to read the read record (S707). The sub-application unit 18B receives the request (S708) and requests the CC-OCC19SB to read the read record. At that time, the sub-application unit 18B refers to the mapping table 201 (mapping table 201 corresponding to Tx1) of the sub-application unit 18B, identifies and identifies that the CC-OCC19S in charge of the read record is the CC-OCC19SB. You may request the CC-OCC19SB to read the read record. The CC-OCC19SB reads the record in response to the request, and stores the read record in the memory of the DB client system 13B (S709). The read record is included in RS ₁ in the snapshot (Tx1 snapshot) managed by CC-OCC19SB. The sub-application unit 18B returns the result to the sub-application unit 18A which is the request source (S710), and the sub-application unit 18A receives the result (S711).

After S704 to S711 are completed for all read records of BL1 _Sub1 , as shown in FIG. 8, S801 to S808 of FIG. 8 are rows for all write records (all records to be written) specified in BL1 _Sub1 . Will be. Take one light record as an example.

The sub-application unit 18A refers to the mapping table 201 (mapping table 201 corresponding to Tx1) of the sub-application unit 18A (S801), and whether or not its own ID corresponds to the ID of the write record (in charge of the light record). Whether or not the sub-application unit 18 that can access the CC-OCC19S is the sub-application unit 18A) is determined (S802). If the determination result of S802 is true, the sub-application unit 18A requests the CC-OCC19SA to write the write record, and the CC-OCC19SA stores the write record in the memory of the DB client system 13A in response to the request. (S803). The write record is included in WS ₁ in the snapshot (Tx1 snapshot) managed by CC-OCC19SA.

If the determination result of S802 is false, the sub-application unit 18A requests the sub-application unit 18B corresponding to the ID of the write record to write (S804). The sub-application unit 18B receives the request (S805) and requests the CC-OCC19SB to write the write record. At that time, the sub-application unit 18B refers to the mapping table 201 (mapping table 201 corresponding to Tx1) of the sub-application unit 18B, identifies and identifies that the CC-OCC19S in charge of the write record is the CC-OCC19SB. You may request the CC-OCC19SB to write a write record. The CC-OCC19SB responds to the request and stores the write record in the memory of the DB client system 13B (S806). The write record is included in WS ₁ in the snapshot (Tx1 snapshot) managed by CC-OCC19SB. The sub-application unit 18B returns the result to the sub-application unit 18A which is the request source (S807), and the sub-application unit 18A receives the result (S808).

After S801 to S808 are completed for all the write records of BL1 _Sub1 , the sub-application unit 18A returns the result of BL1 _Sub1 to the coordinator 16 (S809). The coordinator 16 receives the result (S810).

Next, BL1 _Sub2 starts. Specifically, as shown in FIG. 9, the coordinator 16 requests the sub-application unit 18B to execute BL1 _Sub2 (S901). BL1 _Sub2 may be defined in advance in the sub-application unit 18B, or may be associated with a request dynamically generated by the coordinator 16 and transmitted in S901.

The sub-application unit 18B receives the execution request of BL1 _Sub2 (S902). S903 to S910 are performed for all the read records (all the records to be read) specified in BL1 _Sub2 . Take one lead record as an example.

The sub-application unit 18B refers to the mapping table 201 (mapping table 201 corresponding to Tx1) of the sub-application unit 18B (S903), and whether or not its own ID corresponds to the ID of the read record (in charge of the read record). Whether or not the sub-application unit 18 that can access the CC-OCC19S is the sub-application unit 18B) is determined (S904). If the determination result of S904 is true, the sub-application unit 18B requests the CC-OCC19SB to read the read record, the CC-OCC19SB reads the record in response to the request, and the read record is stored in the DB. It is stored in the memory of the client system 13B (S905). The read record is included in RS ₂ in the snapshot (Tx1 snapshot) managed by CC-OCC19SB.

When the determination result of S904 is false, the sub-application unit 18B is the sub-application unit 18A corresponding to the ID of the read record (the sub-application unit 18 specified from the mapping table 201 and is in charge of the read record CC-OCC19S. Request a read from the accessible sub-application unit 18A) (S906). The sub-application unit 18A receives the request (S907) and requests the CC-OCC19SA to read the read record. The CC-OCC19SA reads the record in response to the request, and stores the read record in the memory of the DB client system 13A (S908). The read record is included in RS ₂ in the snapshot (Tx1 snapshot) managed by CC-OCC19SA. The sub-application unit 18A returns the result to the requesting sub-application unit 18B (S809), and the sub-application unit 18B receives the result (S910).

After S903 to S910 are completed for all read records of BL1 _Sub2 , as shown in FIG. 10, S1001 to S1008 of FIG. 10 are rows for all write records (all records to be written) specified in BL1 _Sub2 . Will be. Take one light record as an example.

The sub-application unit 18B refers to the mapping table 201 of the sub-application unit 18B (S1001), and whether or not its own ID corresponds to the ID of the write record (a sub-application that can access the CC-OCC19S in charge of the light record). Whether or not the unit 18 is the sub-application unit 18B) is determined (S1002). When the determination result of S1002 is true, the sub-application unit 18B requests the CC-OCC19SB to write the write record, and the CC-OCC19SB stores the write record in the memory of the DB client system 13B in response to the request. (S1003). The write record is included in WS ₂ in the snapshot (Tx1 snapshot) managed by CC-OCC19SB.

If the determination result of S1002 is false, the sub-application unit 18B requests the sub-application unit 18A corresponding to the ID of the write record to write (S1004). The sub-application unit 18A receives the request (S1005) and requests the CC-OCC19SA to write the write record. In response to the request, the CC-OCC19SA stores the write record in the memory of the DB client system 13A (S1006). The write record is included in WS ₂ in the snapshot (Tx1 snapshot) managed by CC-OCC19SA. The sub-application unit 18A returns the result to the requesting sub-application unit 18B (S1007), and the sub-application unit 18B receives the result (S1008).

After S1001 to S1008 are completed for all the write records of BL1 _Sub2 , the sub-application unit 18B returns the result of BL1 _Sub2 to the coordinator 16 (S1009). The coordinator 16 receives the result (S1010).

Next, as shown in FIG. 11, the coordinator 16 transmits a preparation request in the two-phase commit to the sub-application unit 18A to which the execution request of BL1 _Sub1 is transmitted (S1101). The sub-application unit 18A receives the request (S1102), requests the CC-OCC19SA for preparation, and the CC-OCC19SA performs the preparation process (S1103). The sub-application unit 18A determines whether or not the preparation process is successful (S1004). If the determination result of S1104 is true, the sub-application unit 18A returns the result (response) of "OK" to the coordinator 16 (S1105). If the determination result of S1104 is false, the sub-application unit 18A returns the result of "NG" to the coordinator 16 (S1106). The coordinator 16 receives the result from the sub-application unit 18 (S1107).

For BL1 _Sub2 , the same processing as S1101 to S1107 of BL1 _Sub1 is performed (S1108 to S1114).

When the coordinator 16 receives the result of the preparation request from all the sub-application units 18 of the preparation request destination, the coordinator 16 determines whether or not all the results are "OK" as shown in FIG. 12 (S1201). ). If the determination result of S1201 is true, the coordinator 16 performs the commit processing of Tx1 (S1202). Specifically, the coordinator 16 transmits a commit request to the sub-application unit 18 (all sub-application units of the destination of the preparation request) of all the sub-business logic destinations regarding Tx1. As a result, each sub-application unit 18 receives the commit request, requests the commit to the CC-OCC19S in response to the commit request, and the CC-OCC19S commits to the DB 521. If the determination result of S1201 is false, the coordinator 16 performs rollback processing (S1203).

In the flow illustrated in FIGS. 7 to 12 above, at least one of the following may be adopted.
-The allocation destinations of BL1 _Sub1 and BL1 _Sub2 may be determined automatically (for example, by the coordinator 16) or manually. For example, a table showing the correspondence between the sub-business logic and the sub-application unit may be prepared, and based on the table, the coordinator 16 specifies the allocation destination of the sub-business logic, and the sub-application unit of the allocation destination is specified. The sub-business logic may be transmitted to.
-The processing of BL1 _Sub1 (S702 to S810) and the processing of BL1 _Sub2 (S901 to S1010) may be performed in parallel.
-Preparation of BL1 _Sub1 (S1101 to S1107) and preparation of BL1 _Sub2 (S1108 to S1114) may be performed in parallel.

The above is the description of this embodiment.

In this embodiment, since the sub-transaction and CC-OCC19S correspond 1: 1 for each transaction, in the above-mentioned invariant, N is the number of sub-transactions and i is the serial number of the sub-transaction (for example, ID). ). However, for at least one transaction, the sub-transaction and CC-OCC19S do not necessarily have a 1: 1 correspondence. Therefore, in the above-mentioned invariant formula, N is the number of CC-OCC19S, and i is the serial number (for example, ID) of CC-OCC19S.

Further, the sub-transaction and the sub-business logic correspond 1: 1, the sub-business logic and the sub-application unit 18 correspond 1: 1 and the sub-application unit 18 and the CC-OCC19S correspond 1: 1. If the records read and / or written between the sub-business logics are non-overlapping for each transaction, the above invariant expression is satisfied.

In the present embodiment, even if the records to be read and / or written are duplicated between the sub-business logics for one transaction, the records are not duplicated between the above-mentioned invariants (that is, CC-OCC19S). ) Is satisfied. This is because if the sub-application unit 18 that can access the CC-OCC19S in charge of the record specified in the sub-business logic is not the sub-application unit 18 that has received the sub-business logic, the read and / or write of the record is , The sub-application unit 18 that received the sub-business logic requests the sub-application unit 18 that can access the CC-OCC19S in charge of the record, and the sub-application unit 18 that receives the request reads the record and / Alternatively, the write request is transmitted to the responsible CC-OCC19S.

The sub-application unit 18 and CC-OCC19S do not necessarily have to be 1: 1. For example, as shown in FIG. 13A, two or more CC-OCC19S may be present in one sub-application unit 18, or two or more CC-OCC19S may be present in one CC-OCC19S as illustrated in FIG. 13B. The sub-application unit 18 may exist. In this case, each sub-application unit 18 will grasp which record is in charge of which CC-OCC19S and which sub-application unit 18 can access the CC-OCC19S based on the mapping table 201. You may be. As a result, the above-mentioned invariant can be satisfied for each transaction.

Further, it is not always necessary that communication is possible between the sub-application units 18. In this case, for example, the records are not duplicated between the sub-business logics for each transaction, and the sub-application unit 18 to which each sub-business logic is assigned is in charge of the record specified in the sub-business logic CC-OCC19S. If the sub-application unit 18 is accessible to, the coordinator 16 transmits each sub-business logic to the sub-application unit 18 (CC-OCC19S) to which the sub-business logic is assigned to obtain the above-mentioned invariant expression. Expected to meet.

Further, for each transaction, the transmission of the preparation request to each sub-application unit 18 that executes the sub-business logic may be performed in one step as illustrated in FIG. 11 depending on the implementation of the isolation level adopted, and is not shown. It may be multi-stage. For example, if the preparation request has two stages, the first stage preparation request may be a request to change the record state to "Prepared" (an example of a state meaning unconfirmed), and the second stage preparation request may be. It may be a validation request that reads a record from DB 521 and checks whether the record matches the record in the memory. The coordinator 16 may execute the commit process (S1202 in FIG. 12) when all the preparation requests are OK from each sub-application unit 18.

Although one embodiment has been described above, these are examples for explaining the present invention, and the scope of the present invention is not limited to these embodiments. The present invention can also be practiced in various other forms.

20: Transaction processing system

Claims (6)

Multiple sub-application departments that execute multiple sub-business logics that make up business logic,
Equipped with multiple CC-OCC,
The plurality of CC-OCCs are provided in a plurality of data source client systems.
The plurality of data source client systems are a plurality of client systems for a data source server system having a plurality of objects.
The data source server system and the plurality of data source client systems are one or more computer systems.
Each object is data that represents the state of the target,
For each of the plurality of sub-application units, the sub-application unit is
In the execution of the sub-business logic, the read request and / or write request of the object to be read and / or written is sent to the CC-OCC in charge of the object.
Each of the plurality of CC-OCCs is configured to perform OCC (Optimistic Concurrency Control) and is a transaction manager of CC (Client Coordinated).
The OCC includes performing validation based on the snapshot at the time of commit.
Each of the plurality of CC-OCCs manages snapshots for each transaction.
For each transaction, a snapshot of that transaction contains a readset, which is a collection of 0 or more read objects, and a writeset, which is a collection of 0 or more write objects.
A read object is an object that has been read in response to an object's read request.
A light object is an object that is lit in response to an object's light request.
For each transaction, the CC-OCC that receives object read requests and / or write requests from two or more sub-application units in the processing of M sub-transactions (M is an integer of 2 or more) that the transaction is divided into. In the case of N CC-OCCs (N is an integer of 2 or more)
The union of N pieces is a pairwise disjoint,
For each of the N unions, the union is the union of the readset and writeset in the snapshot managed by CC-OCC corresponding to the transaction.
For each of the M sub-transactions, the sub-transaction is processed in the execution of the sub-business logic and includes an object read request and / or a write request from the sub-application part to the CC-OCC.
Transaction processing system. Multiple sub-application departments that execute multiple sub-business logics that make up business logic,
Equipped with multiple CC-OCC,
The plurality of CC-OCCs are provided in a plurality of data source client systems.
The plurality of data source client systems are a plurality of client systems for a data source server system having a plurality of objects.
The data source server system and the plurality of data source client systems are one or more computer systems.
Each object is data that represents the state of the target,
Each of the plurality of CC-OCCs is configured to perform OCC (Optimistic Concurrency Control) and is a transaction manager of CC (Client Coordinated).
The OCC includes performing validation based on the snapshot at the time of commit.
Each of the plurality of CC-OCCs manages snapshots for each transaction.
For each transaction, a snapshot of that transaction contains a readset, which is a collection of 0 or more read objects, and a writeset, which is a collection of 0 or more write objects.
A read object is an object that has been read in response to an object's read request.
A light object is an object that is lit in response to an object's light request.
For each transaction, the CC-OCC that receives object read requests and / or write requests from two or more sub-application units in the processing of M sub-transactions (M is an integer of 2 or more) that the transaction is divided into. In the case of N CC-OCCs (N is an integer of 2 or more)
The union of N pieces is a pairwise disjoint,
For each of the N unions, the union is the union of the readset and writeset in the snapshot managed by CC-OCC corresponding to the transaction.
For each of the M sub-transactions, the sub-transaction is processed in the execution of the sub-business logic and includes an object read request and / or a write request from the sub-application part to the CC-OCC.
For each of the plurality of sub-application units, the sub-application unit is
In the execution of the sub-business logic, the person in charge makes a judgment as to whether or not the sub-application department is in charge of the sub-application department.
The responsible sub-application unit is a sub-application unit capable of transmitting an object read request and / or a write request to the responsible CC-OCC of the object to be read and / or written.
If the result of the charge determination is true, the read request and / or write request of the object is transmitted to the CC-OCC in charge of the object in the data source client system having the sub-application part.
If the result of the judgment in charge is false, the sub-application part in the data source client system having the CC-OCC in charge of the object is requested to read and / or write the object.
Transaction processing system. Mapping information indicating which object is in charge of which sub-application part or which CC-OCC is stored in each of the plurality of data source client systems.
Each of the plurality of sub-application units makes the above-mentioned charge determination based on the mapping information in the data source client system having the sub-application unit.
The transaction processing system according to claim 2. Further, a coordinator provided inside or outside at least one of the plurality of sub-application units is provided.
The coordinator
Start a transaction and
Request the sub-application department to execute the sub-business logic for each of the multiple sub-business logics related to the started transaction.
When a predetermined response of the sub-business logic is received from the sub-application unit that executes the sub-business logic for each of the plurality of sub-business logics, one or more preparation requests are made to each of the plurality of sub-application units. And send
When a predetermined response is received from each sub-application unit for all the preparation requests sent to the sub-application unit, a commit request is transmitted to each of the plurality of sub-application units.
The transaction processing system according to any one of claims 1 to 3. The steps to execute the sub-business logic by the sub-application part in the data source client system,
In executing the sub-business logic, it has a step of transmitting a read request and / or a write request of the object to be read and / or written to the CC-OCC in charge of the object.
Multiple sub-applications that execute multiple sub-business logics that make up the business logic are provided in multiple data source client systems for a data source server system with multiple objects.
The data source client system is one of the plurality of data source client systems.
The sub-application unit is one of the plurality of sub-application units.
The data source server system and the plurality of data source client systems are one or more computer systems.
Each object is data that represents the state of the target,
The plurality of data source client systems have a plurality of CC-OCCs, and the plurality of data source client systems have a plurality of CC-OCCs.
Each of the plurality of CC-OCCs is a CC (Client Coordinated) transaction manager that performs OCC (Optimistic Concurrency Control).
The OCC includes performing validation based on the snapshot at the time of commit.
Each of the plurality of CC-OCCs manages snapshots for each transaction in the data source client system having the CC-OCC.
For each transaction, a snapshot of that transaction contains a readset, which is a collection of 0 or more read objects, and a writeset, which is a collection of 0 or more write objects.
A read object is an object that has been read in response to an object's read request.
A light object is an object that is lit in response to an object's light request.
For each transaction, the CC-OCC that receives object read requests and / or write requests from two or more sub-application units in the processing of M sub-transactions (M is an integer of 2 or more) that the transaction is divided into. In the case of N CC-OCCs (N is an integer of 2 or more)
The union of N pieces is a pairwise disjoint,
For each of the N unions, the union is the union of the readset and writeset in the snapshot managed by CC-OCC corresponding to the transaction.
For each of the M sub-transactions, the sub-transaction is processed in the execution of the sub-business logic and includes an object read request and / or a write request from the sub-application part to the CC-OCC.
Method. In the execution of the sub-business logic, the sub-application department in the data source client system determines whether or not the sub-application department is the responsible sub-application department.
If the result of the judgment in charge is true, the sub-application unit transmits a read request and / or a write request for the object to the CC-OCC in charge of the object in the data source client system having the sub-application unit. Steps and
If the result of the charge determination is false, the sub-application department requests another sub-application department in another data source client system having the CC-OCC in charge of the object to read and / or write the object. Have steps and
Multiple sub-applications that execute multiple sub-business logics that make up the business logic are provided in multiple data source client systems for a data source server system with multiple objects.
The data source client system is one of the plurality of data source client systems.
The other data source client system is one of the plurality of data source client systems and is a data source client system different from the data source client system.
The sub-application unit is one of the plurality of sub-application units.
The other sub-application unit is one of the plurality of sub-application units, and is a sub-application unit different from the sub-application unit.
The data source server system and the plurality of data source client systems are one or more computer systems.
Each object is data that represents the state of the target,
The plurality of data source client systems have a plurality of CC-OCCs, and the plurality of data source client systems have a plurality of CC-OCCs.
Each of the plurality of CC-OCCs is a CC (Client Coordinated) transaction manager that performs OCC (Optimistic Concurrency Control).
The OCC includes performing validation based on the snapshot at the time of commit.
Each of the plurality of CC-OCCs manages snapshots for each transaction in the data source client system having the CC-OCC.
For each transaction, a snapshot of that transaction contains a readset, which is a collection of 0 or more read objects, and a writeset, which is a collection of 0 or more write objects.
A read object is an object that has been read in response to an object's read request.
A light object is an object that is lit in response to an object's light request.
For each transaction, the CC-OCC that receives object read requests and / or write requests from two or more sub-application units in the processing of M sub-transactions (M is an integer of 2 or more) that the transaction is divided into. In the case of N CC-OCCs (N is an integer of 2 or more)
The union of N pieces is a pairwise disjoint,
For each of the N unions, the union is the union of the readset and writeset in the snapshot managed by CC-OCC corresponding to the transaction.
For each of the M sub-transactions, the sub-transaction is processed in the execution of the sub-business logic and includes an object read request and / or a write request from the sub-application part to the CC-OCC.
Method.

Images