JP2002334004A - Transaction managing device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a transaction managing device which eliminates the need for a recovery process, conserves resources and energy, and can be actualized speedily. SOLUTION: A start request for update and the ID of a variable (i) are received from a host device and an update starting device confirms that no other devices is in updating operation by using an update counter C, copies variables 1 to (n) that a switch S indicates to a record saving area RS, and sends the contents of the variable (i) copied in the RS to the host device, but when some other host device is in updating operation, the contents of the variable (i) in the RS are sent to the host device; and an end request for the update and the contents M of the variable (i) having been updated are received from the host device. An update ending device stores the variable (i) stored in a record in the RS and confirms that no other host device is updating the variable by using the C, copies the contents of the record in the RS to the opposite record from the record that the S indicates, and changes the S so that the opposite record is indicated.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a transaction management apparatus for simultaneously executing a plurality of transactions inseparably.

[0002]

2. Description of the Related Art There is a case where a certain transaction process is performed over a plurality of transactions. For example, a transaction that updates a variable that manages the balance (hereafter,
"Tr1") and points (for example,
It is assumed that there is a transaction (hereinafter, referred to as “Tr2”) for updating a variable for managing points according to the purchase amount of a product. If there is a transaction to purchase a certain product (hereinafter “Tr3”),
Suppose that the purchase price is made by Tr1, and the points are updated by Tr2.

At this time, the product purchase process (Tr3) must be a simultaneous inseparable process. That is, it is necessary to ensure that all the transactions of Tr1 to Tr3 are executed completely or not at all. Because, when Tr1 and Tr2 were executed during the processing of Tr3, if any of them failed, the point was not increased even though the price was reduced, or the price was reduced and the points increased. This is because a situation occurs in which the product is not purchased. In other words, it is necessary to guarantee that the product is purchased and the price is reduced and points are increased, or that there are only two states in which the product is not purchased, the price is not reduced and the points do not increase. There is.

[0004] In the prior art, first, before performing the processing of Tr1 to Tr3, all the updated variables are backed up and then the variables are updated. In this method, if even one of Tr1 to Tr3 fails, the backup can be written back to a variable (recovery process) to return to the state before the process was started. As a result, all executions of Tr1 to Tr3 can be made simultaneously inseparable. Tr1 to Tr3
FIG. 22 shows an example of the processing sequence of FIG. 22, and FIG. 23 shows a configuration diagram of the transaction management device connected to the higher-level device.

[0005] The host device is a device that executes each transaction. Further, the transaction management device includes a commit buffer monitor, a commit buffer, and a data storage area. The commit buffer is an area provided on a nonvolatile storage area for storing a backup of a variable. The commit buffer monitor is a function for creating all backups to be updated before updating. When the sequence in FIG. 22 is executed using the apparatus in FIG. 23, the following is performed. 1. The host device that performs Tr3 declares that a transaction is to be started to the transaction management device. 2. The transaction management device creates a backup of the variable updated in Tr3 on the commit buffer. 3. The upper device that performs Tr3 updates the purchase history and calls the upper device that performs Tr1 to make payment. If the update of the purchase history has failed, the procedure shifts to 13. 4. The host device that executes Tr1 declares that a transaction is to be started to the transaction management device. 5. The transaction management device creates a backup of the variable updated in Tr1 on the commit buffer. If the update of the balance has failed, the process proceeds to step 13. 6. The host device executing Tr1 updates the balance and calls the host device executing Tr2 to increase the points. 7. The host device executing Tr2 declares that a transaction is to be started to the transaction management device. 8. The transaction management device creates a backup of the variable updated in Tr2 on the commit buffer. 9. The higher-level device that performs Tr2 increases the points, and when the update is successful, declares the completion of the transaction to the transaction management device and returns control to the higher-level device that performs Tr1. If the point update has failed, the procedure moves to 13. 10. Tr1 completes its own processing and Tr2, that is, completes the update of the balance and the update of the points. Therefore, it declares the completion of its own transaction Tr1 to the transaction management apparatus, and returns control to the higher-level apparatus that executes Tr3. 11. In Tr3, since Tr1 has been completed, that is, the update of the purchase history, the update of the balance and the update of the points have been completed, the transaction management device is declared to have completed the transaction. 12. The transaction management device deletes all backups because all transactions have been completed, that is, all transactions of Tr1 to Tr3 have been completely executed. If any one of the processes from 13.1 to 11 fails, the state of all variables is returned to the previous state by writing back the backup on the commit buffer. Whether all transactions are executed completely or not at all,
That is, simultaneous inseparable processing is realized.

[0006]

In the conventional transaction apparatus, since it is necessary to back up all variables to be updated, a storage area for the variables is required, and the number, combination, and order of the variables to be updated are reduced. Become complicated,
That is, as the number of transactions increases, it is necessary to prepare more storage areas. At least one extra write to the storage area is required for backup, but writing to the non-volatile storage area generally requires a high time cost, so that high-speed processing can be performed. difficult. At the end of the update, it is necessary to delete the backup. Furthermore, in order to enable simultaneous inseparability with this device, a recovery function that writes back all backups when any update fails in the event of a failure is essential, but the number, combination, and If the order becomes complicated, complicated recovery processing is required. Therefore, it is difficult to realize resource saving and high-speed processing according to the conventional technology for the above-described reason.

[0007]

In order to solve the above-mentioned problems, the present invention according to claim 1 is a method in which a variable 1 to 4
Transaction management that, when instructed to update the contents of one or more variables out of n (n is an arbitrary integer) in an arbitrary combination and order, makes the update an inseparable process. In the apparatus, the transaction management device includes an update start device, an update counter, an update end device, a memory having a record storage area for storing two variables 1 to n, and a memory having a pointer record save area for storing variables 1 to n. And a switch that points to one of the two record storage areas, and the higher-level device stores a variable i (1 ≦
When an update of i ≦ n) is to be started, a start request is received, and the update start device checks whether or not another higher-level device is updating a variable by using an update counter. Is not performed, the update counter is incremented, the contents of the record storage area pointed to by the switch are copied to the pointer record save area, and the contents of the variable i stored in the record in the record save area are transferred to the higher-level device. If another update is being performed, the update counter is incremented, the contents of the variable i stored in the record in the pointer record save area are sent to the higher-level device, and the higher-level device updates the variable i. , The update end device receives the end request and the updated content M of the variable i from the higher-level device, and stores it in the variable i stored in the record on the record save area. The new counter is decremented, the update counter is used to confirm that no other host device is updating the variable, and if no other update has been performed, the record storage pointed to by the switch points to the contents of the record in the record save area. The copy is made to the record storage area opposite to the area, and the switch is changed to point to the record storage area on the opposite side to the present.

[0008] According to a second aspect of the present invention, an arbitrary higher-level device
When one or more variables of variables 1 to n (n is an arbitrary integer) are instructed to update their contents in an arbitrary combination and order, the update can be performed as an inseparable process. A transaction management device that enables the update history to be traced back by a rollback instruction, wherein the transaction management device includes an update start device,
Update counter, update end device, memory having record storage area for storing two or more variables 1 to n, variables 1 to n
A memory having a pointer record save area for storing
A switch pointing to two or more record storage areas, a rollback device, and when the higher-level device attempts to start updating the variable i (1 ≦ i ≦ n), it receives a start request from the higher-level device, The update start device checks using the update counter whether or not another higher-level device is updating the variable, and if no other update has been performed, increments the update counter, and the switch The contents of the record storage area storing the indicated variables 1 to n are copied to the record save area, the contents of the variable i stored in the record in the record save area are sent to the higher-level device, and another update is performed. If it is during the update, the update counter is incremented, and the contents of the variable i stored in the record in the record save area are sent to the higher-level device. The contents M of the request and the updated variable i
Is passed to the update end device, and the update end device stores M in the variable i stored in the record in the record save area.
The update counter is decremented, the update counter is used to confirm that no other host device is updating the variable, and if no other update has been performed, the contents of the record in the record save area are switched. Is copied to the record storage area next to the record storage area indicated by, the value of the switch is increased by one, and changed to point to the current next record storage area;
Also, when a higher-level device instructs a rollback after updating the contents of one or more of the variables 1 to n in any combination and order, the number of stages r (r is (An integer of 1 or more) is passed to the rollback device, and the rollback device changes r from the current switch value and changes the record storage area indicated by the switch.

According to a third aspect of the present invention, an arbitrary higher-level device
One of structures 1 to n (n is an arbitrary integer) on the storage area
A transaction management device that, when instructed to update the contents of one or more structures in an arbitrary combination and order, enables the update to be performed as an inseparable process. An update start device, an update counter, an update end device, a memory having a record storage area for storing two log indexes 1 to n, a memory having a pointer record save area for storing log indexes 1 to n, and n indexes A memory having a structure storage area storing the contents, a switch pointing to one of the two record storage areas is provided, and when the host device starts updating the structure i (1 ≦ i ≦ n), The update request is received from the device and passed to the update start device, and the update device determines whether or not another higher-level device is updating the structure. If no other update has been performed, the update counter is incremented, and the contents of the record storage area storing the log indexes 1 to n indicated by the switch are copied to the record save area, and the record is saved. The contents of the log pointed to by the log index unique to the structure i stored in the record in the area are passed to the upper-level device. If another update is being performed, the update counter is increased, and the record save area is increased. The contents of the log indicated by the log index unique to the structure i stored in the upper record are passed to the higher-level device, and the higher-level device transmits the variable i (1 ≦ i ≦
When the update of n) is to be terminated, a termination request is received from the higher-level device and passed to the update termination device.
The update counter is decremented, the new contents of the structure i passed from the higher-level device are copied to a log different from the log indicated by the log index unique to the variable i stored in the record in the record save area, and the location is changed. Updates the log index stored in the record in the record save area to point to, using the update counter to confirm that no other higher-level device is updating the variable, and if no other update has been performed The contents of the record in the record save area are copied to the record storage area opposite to the record storage area indicated by the switch, and the switch is changed to point to the record storage area on the opposite side from the current one.

The transaction device of the present invention does not need to have a backup to be updated on a nonvolatile storage device, and all updates can be performed on a volatile storage area. Generally, writing to a volatile storage area can be performed much faster than writing to a non-volatile storage area.
The time cost due to writing to the nonvolatile storage area can be reduced. Also, with the conventional technology, the original variables are not modified at the time of updating, so if any update fails, all variables can be automatically returned to the state before the update, and a complicated recovery function is required Disappears.
In addition, in order to simultaneously update any combination or order of one or more variables, all updates must be confirmed at the same time. However, with the conventional technology, the backup area must be cleared, Although it takes time in proportion to the number of records, it can be performed within a fixed time because it can be performed only by switching records with the present technology. Therefore, for the above reasons, the transaction management device
Resource saving and high speed realization.

[0011]

Embodiments of the present invention will be described. (Embodiment 1) FIG. 1 shows the configuration of a transaction management apparatus of Embodiment 1. The transaction management device includes an update start device, an update counter C (initial value is set to 0), an update end device, a reference device, and two devices (# 0, #
1) A record storage area for storing the variables 1 to n of 1), a pointer record save area RS (work area) for storing the variables 1 to n on the volatile memory, and a switch S for switching the record storage area.

The operation of the transaction management device will be described. The host device is a variable i (1 ≦ i ≦ n, n: any integer)
When the update is to be started, the transaction management device receives the start request and the ID (identifier) of the variable i from the higher-level device and passes it to the update start device, and the other upper-level device is updating the variable. Is confirmed using the update counter C, that is, if the update counter C is 0,
C is incremented by one, and the contents of the records (variables 1 to n) storing the variables 1 to n (# 0) indicated by the switch S are copied to the pointer record save area RS, and the record save area R
The content of the variable i stored in the record on S is sent to the host device, and if the update counter C is other than 0, that is, if the update is being performed, the update counter C is incremented by one.
The contents of the variable i stored in the record in the record save area RS are sent to the host device.

When the higher-level device attempts to end the update of the variable i, the transaction management device receives a termination request and the updated content M of the variable i from the higher-level device and passes it to the update ending device. M is stored in the variable i stored in the record in the pointer record save area RS, the update counter C is decremented by 1, and it is confirmed using the update counter C that no other higher-level device is updating the variable, If the update counter C is 0, that is, if no other update has been performed, the contents of the record in the record save area RS are copied to the record storage area (# 1) opposite to the record storage area indicated by the switch S, The switch S is changed to point to the record storage area (# 1) on the opposite side from the current one.

The reference device receives the reference request from the upper device and the ID of the variable i, and transmits the stored contents of the variable i to the higher device.

Embodiment 1 will be described in detail. FIG. 4 shows a configuration example of an IC card to which the present invention is applied. This IC card includes an input / output control unit (I / O) for controlling data input / output with a card reader / writer (R / W), a microprocessor (CPU), a ROM, a RAM, and an EEPROM. RAM is CPU
Is a volatile storage area used for executing the program, ROM is a memory for storing the program executed by the CPU, and EEPROM is a non-volatile storage area for the program to store data. The present invention relates to a CPU, R
Update means is realized by OM, RAM, and EEPROM.

FIG. 5 is an explanatory diagram of the contents of the RAM and the EEPROM. In the present embodiment, the switch S of the record, the log of the record (two), and the log of the variable (2 × the number of variables) are prepared in the EEPROM. The log is composed of two areas, and stores the current value and the previous value of each variable (or record), respectively.

The record has the structure shown in FIG.
In each field, information indicating which of the two logs (# 0, # 1) of each variable stores the current variable value is stored. The switch S of the record stores information indicating which of the logs of the two records stores the current value. The RAM is provided with a work area (pointer record save area RS) for storing a temporary value of each variable (record) and an update counter for counting the number of transactions being executed.

FIG. 7 is a functional block diagram of the present invention realized by the CPU according to the control program stored in the ROM. The transaction management device performs EEPROM and RAM, and updates the variables managed by logs on the EEPROM across multiple transactions simultaneously and inseparably.
The higher-level device is an entity that performs a variable update transaction, and issues a start request and an end request to the transaction management device before and after the transaction. Upon receiving the start request, the transaction management device copies the value of the variable to be updated from the log of the EEPROM to the work area of the RAM according to the sequence of FIG. 8, and the host device updates the work area.

The transaction start sequence is shown below. 1. When a start request is received from a higher-level device, it is determined whether or not the update counter is 0. If it is 0, the process proceeds to 2. If it is not 0, the process proceeds to 3. 2. Copy the record indicated by the record switch S to the work area on the RAM. 3. Increment the update counter by one. 4. Copy the log data indicated by the field corresponding to the variable in the record on the RAM to the work area on the RAM, and finish. When receiving the end request, the transaction management device stores the data in the work area of the RAM in the log of the EEPROM according to the sequence of FIG.

The transaction end sequence is shown below. 1. When a termination request is received from a higher-level device, the contents of the variables in the work area are copied to the one storing the previous state of the variable log. 2. Update the value of the field corresponding to the variable of the record in the work area with the information in the log in which the contents of the variable in the work area are copied. 3. Decrease the update counter by one. 4. Judge whether the update counter is 0 or not. If it is 0, the process proceeds to 5. If it is not 0, the process ends. 5. Copy the record in the work area to the record opposite to the record indicated by the record switch. 6. The record switch S is switched, and the process ends.

Next, a case where the processing shown in FIG. 10 is performed using this embodiment will be described. The process of FIG. 10 shows an example in which a transaction (Tr2) is further generated from a certain transaction (Tr1). TR in FIG.
The higher-level devices that perform 1, TR2 are referred to as point AP and electronic cash AP, respectively. Point AP manages points with variables,
Update is performed in own transaction (Tr1), and payment processing is performed using the electronic cash AP. The electronic cash AP manages the balance with a variable and updates it with its own transaction (Tr2). At this time, the execution of Tr1 and Tr2 must be simultaneously inseparable. Because, when Tr2 is performed in Tr1, if either transaction fails, points will increase even though payment has not been made, or points will not increase even though payment is completed It is. At this time, as shown in FIG. 11, a record switch and two records having two fields (#
1, # 2), variable log updated with electronic cash AP (balance log), variable log updated with point AP (point log)
Are respectively prepared (# 0, # 1). The RAM has a work area for records, a work area for each variable, and an update counter.

FIG. 12 shows a host device (electronic cash AP, point A).
P) and the transaction sequence of the transaction management device.
The figure explaining the contents of OM and RAM is shown. Here, the number of each log is represented by #, and the respective initial values are as follows (see FIG. 13 (initial)). -Update counter 0-Record switch 0-Record log # 0 10-Record log # 1 00-Balance log # 0 300-Balance log # 1 200-Point log # 0 40-Point log # 1 30 Meaning of the above initial values Has no transaction since the update counter is 0. Since the record switch is 0, the record log # 0 stores the value of the current record. If the first field of the record log stores the information of the balance log and the second field stores the information of the point log, the value of the record log # 0 is 10, so the current balance value is stored in the balance log. # 1, ie, 200 yen, and the point log # 0, ie, 40 points, which stores the current point value.

The sequence will be described with reference to FIGS. (1) The point AP issues a start request to the transaction management device to start its own transaction Tr1. The transaction management device receives this request, and the update start device checks the update counter, and since it is 0, increments the counter by one (update counter [1]) and records the contents of the record log [# 0] indicated by the record switch as a record. Copy to work area (record work area [10])
(i). Further, information of a log (point log # 0 [40]) storing the current value of the variable (point) updated by the point AP is obtained from the record log on the work area, and the value is copied to the work area of the point. (ii). (2) Point AP calls electronic cash AP to make payment. (3) The electronic cash AP issues a start request to the transaction management device to start its own transaction Tr2. In the transaction management device, the update counter is checked, and since it is not 0, the counter is increased by one (update counter).
[2]), information of a log (balance log # 1 [200]) storing the current value of the variable (balance) updated by the electronic cash AP is obtained from the record log (# 0 [1]) on the work area. Then, the value is copied to the balance work area (iii). (4) Electronic cash AP reduces (updates) the balance on the work area
Yes (payment [100]: balance work area [100])
(Iv). (5) The electronic cash AP issues a termination request to the transaction management device to terminate its own transaction Tr2.

The transaction management device receives the end request, and the update end device sets the balance [100] on the work area.
Is stored in the log (# 0) storing the value immediately before the balance log, the value of the record in the work area is updated to the information of the log stored earlier (# 0 [0]), and further updated The counter is checked, and since it is not 0, the counter is reduced by one (update counter [1]) (v). (6) The electronic cash AP returns control to the point AP. (7) Point AP is the number of points [1] according to the payment amount [100]
0], the number of points on the work area is increased (point work area [50]) (vi). (8) The point AP issues a termination request to the transaction management device to terminate its own transaction Tr1.

The transaction management device stores the number of points [50] in the work area in the log (# 1) storing the value immediately before the point log, and stores the value of the record in the work area just before. The record is updated to the information of the log (# 1), and the update counter is checked. Since the value is 0, the record in the work area is copied to the record (record log # 1) opposite to the record indicated by the record switch (v
ii) Further, the record switch is switched so as to point to the record copied earlier (record switch [1] (v
iii). At this point, the updates performed on Tr1 and Tr2 are deterministic. This is because the switch storing the information of the log storing the value of each variable is switched by the switch, and thereafter, the value of each variable is determined based on the information of the switched record.

This embodiment has three features. The first is
This method can be realized with very simple control, and most updates can be performed in the work area on the RAM, so that it can be realized at high speed and can be applied to a form with very limited resources such as an IC card.

Second, unlike the prior art, there is no need for recovery processing when a failure occurs. The reason for determining the value of each variable in this method is the value of the log pointed to by the record indicated by the record switch. This is because, in the above example, the original value is not changed at all in each update process, and all updates until the last record switch is switched are treated as temporary updates. In other words, even if a failure occurs, the information indicating the log of each variable on the valid record is not changed unless the record switch is switched, all updates are automatically canceled, and the state returns to the state at the start of processing . In addition, since the switching of the record switch can be performed by updating one bit, the atomicity of the update is guaranteed.

Third, in the present method, the value of each variable is managed by two logs of the current state and the previous two states, and further indicates which log of each variable is the current state. Information 1
One record is collected, and the record itself is managed by two logs of the current state and the previous state. Therefore, a single operation of switching the log of a record can switch the state of the log of all variables managed in the record, that is, update the values simultaneously, thereby realizing simultaneous inseparability of a plurality of transactions. are doing. Further, even if the number of transactions to be executed inseparably increases, the record itself for managing the state of the log of the variable may be lengthened, and the simultaneous update can be performed within a certain time when the record switch is switched.

(Embodiment 2) In Embodiment 2, roll back
That is, the second embodiment is different from the first embodiment in that a process for restoring the changed data in the database when the transaction ends without committing is provided. FIG. 2 illustrates a configuration of the transaction management device according to the second embodiment. The transaction management device includes an update start device, an update counter C (initial value is 0), an update end device, a reference device, and two or more (# 0, # 1,...) Variables 1 in the nonvolatile memory. To n (n is an arbitrary integer), a pointer record save area RS (work area) for storing variables 1 to n on the volatile memory, a switch S for switching the record storage area, and rollback. It is composed of devices.

The operation of the transaction management device will be described. When the higher-level device attempts to start updating the variable i (1 ≦ i ≦ n), it receives a start request from the higher-level device and passes it to the update start device. The other upper-level device is updating the variable. It is confirmed that the update counter C is not 0, and if the update counter C is 0, that is, if no other update has been performed, the update counter C is incremented by one and the switch S points to
The contents of the record storage area (# 0) storing the variables 1 to n are copied to the pointer record save area RS, and the contents of the variable i stored in the record in the pointer record save area RS are sent to the host device and updated. If the counter C is other than 0, that is, if another update is being performed, the update counter is incremented by one, and the contents of the variable i stored in the record in the pointer record save area RS are sent to the upper-level device. When the higher-level device attempts to end the update of the variable i, a termination request from the higher-level device and the content M of the updated variable i
Is passed to the update end device, and the update end device receives the variable i stored in the record in the record save area RS.
To store the content M of the variable i, decrement the update counter by one,
Using the update counter C, it is confirmed that the variable is not being updated by another host device. If the update counter C is 0, that is, if no other update has been performed, the contents of the record in the pointer record save area RS are deleted. Copy to the record storage area (# 1) next to the record storage area indicated by the switch S,
The value of the switch S is increased by one, changed to point to the current next record storage area (# 1), and the above operation is sequentially repeated.

When a rollback is instructed after updating the contents of one or more of the variables 1 to n in an arbitrary combination and order from an arbitrary higher-level device, when the upper-level device specifies the number of steps r (R is an integer equal to or greater than 1) and passes it to the rollback device. The rollback device subtracts r from the current value of the switch S and changes the record storage area indicated by the switch S.

(Embodiment 3) In Embodiment 3, instead of storing variables 1 to n in the two record storage areas of Embodiment 1, log indexes 1 to n are stored, and logs 1 to n are stored respectively. Is provided in that structures 1 to n are provided.

FIG. 3 shows the configuration of the transaction management apparatus according to the third embodiment. The transaction management device stores a record storage area that stores the update start device, the update counter C (initial value is 0), the update end device, the reference device, and two (# 0, # 1) log indexes 1 to n. Memory, a memory having a pointer record save area RS for storing the log indexes 1 to n, a switch S for switching records in the record area, and n structures each constituting a log. The operation of the transaction management device will be described.

When the higher-level device attempts to start updating the structure i, the transaction management device receives a start request from the higher-level device and passes it to the update start device. It is confirmed by using the update counter C that it is not in the middle, and if C is 0, that is, if no other update has been performed, C is incremented by one and the record storage storing the log indexes 1 to n indicated by the switch S is stored. region(#
0) is copied to the pointer record save area RS, and the contents of the log pointed to by the index unique to the structure i stored in the record in the pointer record save area RS are passed to the host device. In other words, if another update is being performed, the update counter C is incremented by one, and the contents of the log indicated by the log index unique to the structure i stored in the record in the pointer record save area RS To the host device.

When the host device attempts to end the update of the variable i, the transaction management device receives a termination request from the host device and passes it to the update end device.
Increment the update counter C by one and copy the new contents of the structure i passed from the higher-level device to a log different from the log indicated by the log index unique to the variable i stored in the record in the pointer record save area RS Then, the log index stored in the record in the pointer record save area RS is updated so as to point to the location, and it is confirmed using the update counter C that no other higher-level device is updating the variable. 0, that is, if no other update has been performed, the contents of the record in the pointer record save area RS are copied to the record storage area (# 1) opposite to the record storage area indicated by the switch S, and the switch S Change to point to the record storage area on the opposite side from the current one.

Embodiment 3 will be described in detail. The configuration example of the IC card to which the present invention is applied is the same as that of the first embodiment. The difference between this embodiment and the first embodiment is that the means for updating the contents of the EEPROM and the data to be actually updated is delegated to a higher-level device, and the degree of freedom is increased depending on the type and structure of the target variable. It is. FIG. 14 is an explanatory diagram of the contents of the RAM and the EEPROM of the transaction management device. In the present embodiment, E
In EPROM, record switch, record log (2
Book), a database DB managed by each host device (the type and structure of each DB depends on the host device), that is, a structure is prepared.

The record has a structure as shown in FIG. 15, and the type of data stored in each field is not particularly defined. The record switch stores information indicating which of the logs of the two records stores the current value. The RAM is provided with a work area for storing a temporary value of the record and an update counter for counting the number of transactions being executed. FIG.
FIG. 3 is a functional block diagram of the present invention realized by a CPU according to a control program stored in a ROM.

The transaction management device is an EEPROM and a RAM.
The DB update transaction executed by each host device in the EEPROM in an arbitrary order is performed simultaneously and inseparably. The host device is an entity that performs a DB update transaction on the EEPROM, issues a start request to the transaction management device when the transaction starts, and receives information stored in a field in a record of the transaction management device in response to the request. Then, at the time of termination, a termination request is made to the transaction management device.

When the transaction management device receives a start request from the host device, it performs processing according to the sequence shown in FIG. The transaction start sequence is shown below. 1. When a start request is received from a higher-level device, it is determined whether or not the update counter is 0. If it is 0, the process proceeds to 2. If it is not 0, the process proceeds to 3. 2. Copy the record indicated by the record switch to the work area on the RAM. 3. Increment the update counter by one. 4. The information stored in the field in the record on the RAM is sent to the higher-level device, and the process ends.

The host device receives the information (index) stored in the field in the record of the transaction management device, updates the DB, and passes the updated DB information together with the end request to the transaction management device. The transaction management device processes the DB information received from the host device according to the sequence shown in FIG. The transaction end sequence is shown below. 1. When a termination request is received from a higher-level device, information received from the higher-level device is stored in a field of a record in the work area. 2. Decrease the update counter by one. 3. Determine whether the update counter is 0 or not. If it is 0, the process proceeds to 4. If it is not 0, the process ends. 4. Copy the record in the work area to the record opposite to the record indicated by the record switch. 5. Switch the record switch and finish.

Next, a case in which an arbitrary plurality of databases are simultaneously and indivisiblely updated will be described. In this example, the case of two databases (ticket DB and log DB) will be described. There is a higher-level device (electronic ticket AP) having a function of executing two transactions, Tr1 and Tr2. Tr1, Tr2
Each is a transaction that performs the following processing. Tr1 is an electronic ticket AP upon request from outside
Search the applicable ticket from the ticket DB in the, and update the ticket (gates etc.). Tr2 writes the update record of the ticket in the usage log DB in the electronic ticket AP.

At this time, a record switch is provided on the EEPROM,
In addition to two records having two fields, a ticket DB used for Tr1 and a use log DB used for Tr2 are prepared. FIG. 19 shows the structure of each DB on the EEPROM of the transaction management device. The RAM has a work area for records, a work area for each variable (pointer record save area RS), and an update counter. As shown in FIG. 19, the record log is provided with two fields (Tr1, Tr2) in two (# 0, # 1) record storage areas, and a DB (structure) that can be written next to each field. Field (index).

At this time, the electronic ticket AP executes a transaction composed of Tr1 and Tr2, that is, executes an electronic ticket (updates the ticket DB) and simultaneously leaves a history (updates the use log) in an inseparable manner. Here is an example. FIG. 20 shows the sequence of the host device (electronic cash AP) and the transaction management device, and FIG. 21 shows the contents of the EEPROM and RAM of the transaction management device. Record switch, record log, ticket DB, log DB
Is assumed to be as shown in FIG. (1) The electronic ticket AP uses ticket D to start processing.
The start of the update transaction Tr1 of B is notified to the transaction management device. (2) In the transaction management device, the update counter C is checked, and since it is 0, the counter is incremented by one, and the contents [24] of the record log (# 0) indicated by the switch of the record are copied to the work area of the record. Then, the value [2] stored in the Tr1 field of the record log on the work area is returned. Here, the electronic ticket AP that has received the value from the transaction management device treats the value as indicating a writable address [2] in the ticket DB. (3) The electronic ticket AP searches the ticket DB for a corresponding ticket (referred to as ticket 5) and obtains its address. (4) The data (ticket 5) stored in the address [5] obtained in (3) is copied to the address [2] obtained in (2) (ticket 5 '). (5) The electronic ticket AP updates (reduces the number of times) the data (ticket 5) copied in (3). (6) The electronic ticket AP notifies the transaction management device of the start of the update transaction Tr2 of the usage log DB to leave an update history of the ticket. (7) The transaction management device checks the update counter, and since it is not 0, increments the counter by one and returns the value [4] stored in the Tr2 field of the record log on the work area. The electronic ticket AP that receives the value from the transaction management device treats the value as indicating a writable address in the usage log DB. (8) For the electronic ticket, write the history at the address [4] obtained in (7). (9) The electronic ticket AP is (address [4] +1) mo obtained in (7)
Calculate dN. (N is the size of the log, and is calculated to make the log a ring buffer.) (10) The electronic ticket AP sends the transaction management device with the value [1] calculated in (9) to the Tr to terminate Tr2. Issue a termination request. The transaction management device stores the passed value in the field Tr2 of the record in the work area, checks the update counter, and decrements the counter by one because it is not zero.

(11) The electronic ticket AP issues a termination request to the transaction management apparatus together with the address value [5] obtained in the search in (3) in order to terminate Tr1. The transaction management device stores the value [5] passed in (11) in the Tr1 field of the record in the work area ((1
State after 1) 1), further check the update counter,
0, the record on the work area is replaced with the record (# 0) opposite to the record (# 0) indicated by the record switch.
Copy to 1) (state after (11), part 2), and switch the record switch to point to the record copied earlier (state after (11), part 3).

At this point, the update performed on Tr1 and Tr2 is deterministic. Because, in the ticket DB just before the switch is switched, the address searched in (3) stores the ticket before update, and the address obtained in (2) stores the ticket after update, and in the usage log DB, The update log of the ticket in (4) remains in the address obtained in (7). However, even if a failure has occurred at this point, since the record has not been switched in the transaction management device, after resuming, the information obtained in (2) again will be the address of the place where the updated ticket was to be stored And (7)
Is the same as before. That is, the same location is overwritten again. However, when the record is switched, the information obtained in (2) and (7) thereafter returns the address where the ticket before the update was stored in the case of the ticket DB, and (7 This is because the next address of the log written in) is returned.

In this embodiment, in addition to the features of the first embodiment, which are resource-saving and can be realized at high speed, and that the recovery process is not required, the operation on the data to be actually updated is delegated to a higher-level device. Accordingly, there is a feature that a data structure which can be simultaneously and indivisiblely updated can have high flexibility. For example, in the above example, in Tr1 and Tr2, the meaning of the information received from the transaction management device is interpreted in the higher-level device, and different update methods are performed for the ticket DB and the usage log DB to be updated, respectively. .
In the method of the first embodiment, since the data is updated by the transaction management device, there are a plurality of DBs as in the third embodiment.
One method cannot be adopted, such as a method of searching and updating a free area and a method of updating like a cyclic record. In the third embodiment, by interpreting the information received from the transaction management device as the address at which the value of the currently valid variable is stored, it is possible to use the method as in the first embodiment. That is, any updating method can be adopted depending on the interpretation of the host device.

The transaction management device according to the present invention
It can be composed of a computer having a U, a memory, and the like, a user terminal used by a user serving as an access subject, and a recording medium. The recording medium is a machine-readable recording medium such as a CD-ROM, a magnetic disk device, and a semiconductor memory.The program recorded here is read by a computer, controls the operation of the computer, and is described above on the computer. Each component in the embodiment, that is, an update start device, an update counter, an update end device, a reference device, a rollback device, a switch S, a record storage area on a memory, a pointer record save area RS, a structure, etc. Realize.

[0048]

As described above, according to the present invention, since 1, most of the updates can be performed on the work area on the RAM,
It can be realized at high speed and can be applied to a very limited form of resources such as an IC card. 2, There is no need for recovery processing when a failure occurs unlike the prior art. The two previous states are managed by two logs, and information indicating which log of each variable is the current state is collected into one record. It is managed by two logs of the previous state,
With one operation to switch the log of a record, the state of the log of all variables managed in the record can be switched, and the values can be updated simultaneously, thereby realizing simultaneous inseparability of multiple transactions. 4. Data that has been changed in the database can be restored by a rollback request from a higher-level device. 5. Operation of data to be actually updated is delegated to a higher-level device. Accordingly, a high flexibility can be given to a data structure that can be simultaneously updated inseparably.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a transaction management device according to a first embodiment of the present invention.

FIG. 2 is a configuration diagram of a transaction management device according to a second embodiment of the present invention.

FIG. 3 is a configuration diagram of a transaction management device according to a third embodiment of the present invention.

FIG. 4 is a diagram showing a configuration example of an IC card to which the present invention is applied.

FIG. 5 is an EEPROM of the transaction management device according to the first embodiment;
And a diagram for explaining the contents of RAM.

FIG. 6 is a diagram illustrating the structure of a record according to the first embodiment.

FIG. 7 is a functional block diagram of the transaction management device according to the first embodiment.

FIG. 8 shows a transaction start sequence according to the first embodiment.

FIG. 9 illustrates a transaction end sequence according to the first embodiment.

FIG. 10 illustrates a sequence of a transaction according to the first embodiment.

11 is an explanatory diagram of the contents of an EEPROM and a RAM of the transaction management device in the sequence of FIG. 10;

FIG. 12 shows another sequence of the transaction according to the first embodiment.

13 is an explanatory diagram of the contents of an EEPROM and a RAM of the transaction management device in the sequence of FIG. 12;

FIG. 14 illustrates an EEPROM of the transaction management device according to the third embodiment.
OM and RAM content explanatory view.

FIG. 15 is a diagram illustrating the structure of a record according to the third embodiment.

FIG. 16 is a functional block diagram of a transaction management device according to a third embodiment.

FIG. 17 shows a transaction start sequence according to the third embodiment.

FIG. 18 illustrates a transaction end sequence according to the third embodiment.

FIG. 19 is a diagram illustrating an EEPROM of the transaction management apparatus according to the third embodiment.
OM and RAM content explanatory view.

FIG. 20 illustrates a sequence of a transaction according to the third embodiment.

FIG. 21 is an explanatory diagram of the contents of EEPROM and RAM of the transaction management device in the sequence of FIG. 20;

FIG. 22 shows a sequence of a conventional transaction.

FIG. 23 is a configuration diagram of a conventional transaction management device.

Claims (3)

[Claims] 1. When an update of the contents of one or more of variables 1 to n (n is an arbitrary integer) is instructed in an arbitrary combination and order from an arbitrary higher-level device, the update is performed. In the transaction management device, the transaction management device includes an update start device, an update counter, an update end device, a memory having a record storage area for storing two variables 1 to n, A memory having a pointer record save area for storing variables 1 to n, a switch for pointing to one of two record storage areas, and a higher-level device intending to start updating a variable i (1 ≦ i ≦ n) Receiving the start request, the update start device checks whether or not another host device is updating the variable using the update counter, and if no other update has been performed, the update start device updates the variable. The counter is incremented, the contents of the record storage area pointed to by the switch are copied to the pointer record save area, the contents of the variable i stored in the record in the record save area are sent to the host device, and another update is performed. If the upper-level device is about to finish updating the variable i, the update counter is incremented and the contents of the variable i stored in the record in the pointer record save area are sent to the higher-level device.
The update end device receives the end request and the updated content M of the variable i from the higher-level device, stores it in the variable i stored in the record in the record save area, decrements the update counter, and the other higher-level device Check that the variable is not being updated using the update counter, and if no other update has been performed, copy the contents of the record in the record save area to the record storage area opposite to the record storage area indicated by the switch And a switch for changing the switch to point to a record storage area on the opposite side to the current one. 2. When an upper device instructs at least one of variables 1 to n (n is an arbitrary integer) to update its contents in an arbitrary combination and order, the update is performed. A transaction management device that enables the process to be performed simultaneously inseparably and further allows the update history to be traced back by a rollback instruction. The transaction management device comprises: an update start device, an update counter, and an update end device. A memory having a record storage area for storing two or more variables 1 to n, a memory having a pointer record save area for storing variables 1 to n, a switch pointing to two or more record storage areas, and a rollback device When the higher-level device attempts to start updating the variable i (1 ≦ i ≦ n), it receives a start request from the higher-level device, passes it to the update start device, The device uses the update counter to determine whether another higher-level device is updating the variable, and if no other update has been performed, increments the update counter, and indicates the variable 1 to which the switch points. n is copied to the record save area, the contents of the variable i stored in the record in the record save area are sent to the host device, and if another update is being performed. The update counter is incremented, and the contents of the variable i stored in the record in the record save area are sent to the higher-level device. Receiving the content M of the variable i and passing it to the update end device, the update end device stores M in the variable i stored in the record in the record save area, decrements the update counter,
Using the update counter, confirm that the variable is not being updated by another host device, and if no other update has been performed, the next record in the record storage area pointed to by the switch indicates the contents of the record in the record save area. Copy to the storage area, increase the value of the switch by one, and change it to point to the current next record storage area. When the rollback is instructed after updating the contents in an arbitrary combination and order, the number of stages r (r is an integer of 1 or more) is received from the higher-level device and passed to the rollback device. A transaction management apparatus characterized in that r is subtracted from a value of a switch and a record storage area indicated by the switch is changed. 3. An instruction to update the contents of one or more of the structures 1 to n (n is an arbitrary integer) in the storage area in an arbitrary combination and order from an arbitrary host device. A transaction management device that, when performed, makes the update an inseparable process. The transaction management device includes an update start device, an update counter, an update end device, and two log indexes 1 to n. A memory having a record storage area for storing, a memory having a pointer record save area for storing log indexes 1 to n, a memory having a structure storage area for storing n indexes and contents, and two record storage areas A switch that indicates whether a higher-level device starts updating the structure i (1 ≦ i ≦ n), receives a start request from the higher-level device, Handover to the new start device, the update device checks whether the structure is being updated by another host device using the update counter, and if no other update has been performed, increments the update counter. The content of the record storage area storing the log indexes 1 to n indicated by the switch is copied to the record save area, and the content of the log indicated by the log index unique to the structure i stored in the record in the record save area To the higher-level device. If another update is being performed, the update counter is incremented, and the contents of the log indicated by the log index unique to the structure i stored in the record in the record save area are transferred. When the higher-level device attempts to end the update of the variable i (1 ≦ i ≦ n), the higher-level device receives a termination request from the higher-level device and passes it to the update ending device. Decrease the counter, copy the new contents of the structure i passed from the higher-level device to a log different from the log indicated by the log index unique to the variable i stored in the record in the record save area, and point to that location Update the log index stored in the record in the record save area as described above, using the update counter to confirm that no other higher-level device is updating the variable, and if no other update has been performed, Transaction management characterized in that the contents of a record in a record save area are copied to a record storage area opposite to the record storage area pointed to by the switch, and the switch is changed to point to the record storage area opposite to the current one. apparatus.