Method and apparatus for handling transaction

Abstract

A transaction processing method and apparatus are provided. A transaction processing method according to one embodiment of the present invention comprises: a step of recording a first transaction requested by a first application among a plurality of applications to a first database in association with a transaction group ID; a step of recording a second transaction requested by a second application called by the first application among the plurality of applications to a second database in association with the transaction group ID; a step of rolling back the second transaction to the second database in response to a determination that an error occurred during the processing of the second transaction; a step of identifying the first transaction based on the transaction group ID; and a step of rolling back the first transaction to the first database.

Description

Technology Field

[0001] The present invention relates to a transaction processing method. More specifically, it relates to a method and apparatus for processing a series of database transaction groups sequentially requested by multiple applications in a Microservice Architecture (MSA) environment. Background Technology

[0002] Microservice Architecture (MSA) refers to an architecture in which a single service function is divided into multiple smaller units (e.g., applications) to perform the overall service function. Since the entire service is implemented as independent service functions, MSA offers the advantage of facilitating changes and maintenance to the service functions.

[0003] The above-mentioned divided service functions perform independent transactions on the database.

[0004] FIG. 1 is a diagram illustrating an MSA, wherein a plurality of applications, each responsible for an independent service function, are illustrated in FIG. 1. Each of the applications can request a transaction from a database, and each application can be connected to others hierarchically. For example, Application A may be an application at the top layer, and Application D may be an application at the bottom layer.

[0005] According to the hierarchical structure of these applications, to process the entire transaction, the applications may be called in the order of Application A, Application B, Application C, and Application D. Following this order of calls, Application D requests Transaction #1 from the database and returns the processing result of Transaction #1 to Application C; Application C requests Transaction #2 from the database and returns the processing result of Transaction #2 to Application B; Application B requests Transaction #3 from the database and returns the processing result of Transaction #3 to Application A; and finally, Application A requests Transaction #4 from the database to process Transaction #4.

[0006] As described above, in an MSA environment, each application processes different transactions sequentially. However, if an error occurs in any one of the related transactions, a rollback for previously processed transactions may not be performed. For example, if Application D processes Transaction #1 and Application C processes Transaction #2, an error may occur while Application B is processing Transaction #3. In this case, although a rollback for Transaction #3 can be performed in the database, Transactions #1 and #2, which were processed prior to Transaction #3, are not rolled back, resulting in a data inconsistency between the data related to Transactions #1 and #2 and the data related to Transaction #3.

[0007] To prepare for such cases, one can consider a centralized management approach where a central controller is established to manage transactions for each application. However, this centralized approach concentrates the load on the central controller, which can paralyze the entire system if it fails. Furthermore, the centralized approach is applicable only to the same Database Management System (DBMS), making it unsuitable for systems containing heterogeneous DBMSs.

[0008] Meanwhile, one might consider equipping each application with features to monitor transaction errors and roll back them. However, adding these transaction monitoring features can increase development costs, and if changes occur to these additional functions, the entire application must be shut down. If the application is halted for logic changes in this way, the operation of the entire system also comes to a halt. Prior art literature

[0009] Korean Registered Patent Publication No. 10-2109461 The problem to be solved

[0010] The technical problem to be achieved through one embodiment of the present invention is to provide a method and apparatus for processing a series of database transaction groups so that data consistency can be guaranteed in an MSA environment.

[0011] Another technical objective to be achieved through one embodiment of the present invention is to provide a transaction processing method and apparatus applicable even to systems including various heterogeneous DBMSs.

[0012] Another technical objective to be achieved through one embodiment of the present invention is to provide a transaction processing method and apparatus with excellent scalability and compatibility.

[0013] Another technical objective to be achieved through one embodiment of the present invention is to provide a method and apparatus capable of changing the logic for rolling back data without interrupting the application.

[0014] Another technical objective to be achieved through one embodiment of the present invention is to provide a transaction processing method and apparatus capable of reprocessing the rollback of a transaction even if the transaction rollback fails.

[0015] The technical problems of the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by a person skilled in the art from the description below. means of solving the problem

[0016] A transaction processing method according to an embodiment of the present invention for solving the above technical problem may include: a step of recording a first transaction requested to a first database by a first application among a plurality of applications in association with a transaction group ID; a step of recording a second transaction requested to a second database by a second application called by the first application among the plurality of applications in association with the transaction group ID; a step of rolling back the second transaction to the second database in response to a determination that an error occurred during the processing of the second transaction; a step of identifying the first transaction based on the transaction group ID; and a step of rolling back the first transaction to the first database.

[0017] In one embodiment, the first database and the second database may be distinct databases.

[0018] In one embodiment, when the second application is called by the first application, the transaction group ID may be transmitted to the second application by the first application.

[0019] In one embodiment, the transaction processing method may further include the steps of: recording a third transaction requested to a third database by a third application called by a second application among the plurality of applications in association with the transaction group ID; rolling back the third transaction to the third database in response to a determination that an error occurred during the processing of the third transaction; identifying the second transaction and the first transaction based on the transaction group ID; and rolling back the second transaction and the first transaction sequentially.

[0020] In one embodiment, the operation of recording a first transaction requested in the first database can be triggered by the first database.

[0021] In one embodiment, the step of recording a first transaction requested in the first database in association with a transaction group ID may include, if the first transaction is a data update transaction, the step of recording the value of a data entry to be updated prior to the update by the first transaction. In this case, the step of rolling back the first transaction against the first database may include the step of rolling back the first transaction using the recorded value of the data entry to be updated.

[0022] In one embodiment, the step of recording a first transaction requested in the first database in association with a transaction group ID may include, if the first transaction is a data deletion transaction, the step of recording the value of a data entry to be deleted prior to deletion by the first transaction. In this case, the step of rolling back the first transaction against the first database may include the step of rolling back the first transaction using the recorded value of the data entry to be deleted.

[0023] In one embodiment, the determination that an error occurred during the processing of the second transaction may be a determination based on data recorded in the shared storage.

[0024] In one embodiment, the transaction processing method may further include the step of deleting the record of the first transaction and the record of the second transaction in response to a determination that the processing of the first transaction and the second transaction has been successfully completed.

[0025] In one embodiment, the transaction processing method may further include the step of deleting the record of the first transaction and the record of the second transaction in response to a determination that the rollback processing of the second transaction and the first transaction has been successfully completed.

[0026] In one embodiment, the transaction processing method may further include the step of maintaining the record of the first transaction and the record of the second transaction in response to a determination that an error occurred during the rollback processing of the second transaction or the first transaction.

[0027] In one embodiment, the step of recording the second transaction in association with the transaction group ID may include the step of recording the second transaction in a lower layer of the first transaction.

[0028] A computing device according to another embodiment of the present invention for solving the above technical problem comprises one or more processors, a memory for loading a computer program executed by said processors, and a storage for storing said computer program, and said computer program may include instructions for performing operations such as: recording a first transaction requested by a first application among a plurality of applications to a first database in association with a transaction group ID; recording a second transaction requested by a second application called by the first application among the plurality of applications to a second database in association with said transaction group ID; rolling back the second transaction to the second database in response to a determination that an error occurred during the processing of said second transaction; identifying the first transaction based on said transaction group ID; and rolling back the first transaction to the first database.

[0029] A computer-readable non-transient storage medium including instructions according to another embodiment of the present invention for solving the above technical problem may enable the processor, when the instructions are executed by the processor, to perform operations including: recording a first transaction requested by a first application among a plurality of applications to a first database in association with a transaction group ID; recording a second transaction requested by a second application called by the first application among the plurality of applications to a second database in association with the transaction group ID; rolling back the second transaction to the second database in response to a determination that an error occurred during the processing of the second transaction; identifying the first transaction based on the transaction group ID; and rolling back the first transaction to the first database. Brief explanation of the drawing

[0030] Figure 1 is a diagram illustrating an MSA. FIG. 2 is a drawing showing a transaction processing system according to one embodiment of the present invention. Figure 3 is a diagram illustrating the order in which applications are called. Figures 4 and 5 are diagrams illustrating a hierarchical transaction structure recorded in a repository. FIG. 6 is a signal flow diagram for explaining a transaction processing method according to another embodiment of the present invention. FIG. 7 is a flowchart of a transaction processing method according to another embodiment of the present invention. Figure 8 is a drawing for explaining in detail step S130 described with reference to Figure 7. Figure 9 is a drawing for explaining in detail step S135 described with reference to Figure 8. FIG. 10 is a drawing for explaining in detail step S150 described with reference to FIG. 7. FIG. 11 is an exemplary hardware configuration diagram that can implement a computing device in various embodiments. Specific details for implementing the invention

[0031] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. The advantages and features of the present invention, and the methods for achieving them, will become clear by referring to the embodiments described below in detail together with the attached drawings. However, the technical concept of the present invention is not limited to the following embodiments but can be implemented in various different forms. The following embodiments are provided merely to complete the technical concept of the present invention and to fully inform those skilled in the art of the scope of the present invention, and the technical concept of the present invention is defined only by the scope of the claims.

[0032] It should be noted that when assigning reference numerals to the components of each drawing, the same components are assigned the same reference numeral whenever possible, even if they are shown in different drawings. Furthermore, in describing the present invention, if it is determined that a detailed description of related known components or functions could obscure the essence of the invention, such detailed description is omitted.

[0033] Unless otherwise defined, all terms used herein (including technical and scientific terms) may be used in a meaning commonly understood by those skilled in the art to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise. The terms used herein are for describing embodiments and are not intended to limit the present invention. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text.

[0034] Additionally, terms such as first, second, A, B, (a), (b), etc., may be used when describing the components of the present invention. These terms are intended merely to distinguish the components from other components, and the nature, order, or sequence of the components is not limited by such terms. Where it is stated that a component is "connected," "combined," or "joined" to another component, it should be understood that the component may be directly connected or joined to the other component, but that another component may also be "connected," "combined," or "joined" between each component.

[0035] As used in the specification, "comprises" and / or "comprising" do not exclude the presence or addition of one or more other components, steps, actions, and / or elements to the mentioned components, steps, actions, and / or elements.

[0036] Hereinafter, some embodiments of the present invention will be described with reference to the drawings.

[0037] FIG. 2 is a drawing showing a transaction processing system according to one embodiment of the present invention.

[0038] Referring to FIG. 2, a transaction processing system according to one embodiment of the present invention may be configured to include a plurality of applications (11, 21, 31), a plurality of databases (12, 22, 32), a record module (13, 23, 33), a storage (40), and a rollback module (50).

[0039] Multiple applications (11, 21, 31) can perform functions for distributed processing of services for clients and associated transactions in a Microservice Architecture (MSA) environment. The multiple applications (11, 21, 31) can process a series of database transaction groups. The transaction group may include multiple transactions. Each application (11, 21, 31) can process its own transaction by utilizing data contained in the database (12, 22, 32) it accesses. For example, if a task is divided into transaction A, transaction B, and transaction C, application A (11) can request transaction A from database A (12), and application B (21) can request transaction B from database B (22). The database (12, 22, 32) can read, update, delete, or store new data based on the requested transactions.

[0040] Each application (11, 21, 31) may be structured in a hierarchical manner to process transactions. When a task is requested, applications (11, 12, 13) may be called sequentially in order from the top application (11) to the bottom application (31). Additionally, a transaction group ID may be passed to the called applications (11, 21, 31).

[0041] FIG. 3 is a diagram illustrating the order in which applications are called, in which applications A, B, and C are called, and when an application is called, a transaction group ID may be passed to the called application. The transaction group ID may be assigned by the application A (11) placed first or by the record module A (13). In one embodiment, when a task is requested, application A (11) may assign a transaction group ID for task processing. In another embodiment, when application A (11) initiates processing for a new task, the record module A (13) may assign a transaction group ID and pass the assigned transaction group ID to application A (11).

[0042] Each database (12, 22, 32) stores data and may be equipped with a DBMS. Each database (12, 22, 32) may be a distinct database (12, 22, 32). For example, each database (12, 22, 32) may be physically or logically distinct from each other. Additionally, each database (12, 22, 32) may be equipped with a different DBMS. For example, different DBMSs may be equipped for each of the databases A (12), B (22), and C (32). The databases (12, 22, 32) may request the recording of a transaction from the recording module (13, 23, 33) through a trigger function provided by themselves. The trigger function may be provided through the DBMS. Additionally, the database (12, 22, 32) may use a trigger function to provide the value of an entry to be updated or the value of an entry to be deleted to the record module (13, 23, 33) before the database (12, 22, 32) is modified. The value of the entry to be updated is data stored in the database (12, 22, 32) before the update transaction is processed, and is data that has been changed as the update transaction is processed. Additionally, the value of the entry to be deleted is data stored in the database (12, 22, 32) before the deletion transaction is processed, and is data that has been deleted as the deletion transaction is processed.

[0043] The above recording module (13, 23, 33) can record transactions occurring in each application (11, 21, 31) as log data in the storage (40). More specifically, the recording module (13, 23, 33) can record transactions processed by the application (11, 21, 31) in the storage (40) in association with a transaction group ID. The transactions recorded in the storage (40) may include statements and database identification information.

[0044] The above recording module (13, 23, 33) can record a transaction requested by the application (11, 21, 31) to the database (12, 22, 32) in association with the transaction group ID. In one embodiment, the above recording module (13, 23, 33) can record a transaction requested by the database (12, 22, 32) in association with the transaction group ID in the storage (40) when triggering occurs from the database (12, 22, 32). That is, the recording module (13, 23, 33) can record the transaction in association with the transaction group ID in accordance with the request of the database (12, 22, 32). In another embodiment, the recording module (13, 23, 33) monitors the operation of the application (11, 21, 31) and, when the application (11, 21, 31) requests a transaction from the database (12, 22, 32) to process the transaction, the transaction may be recorded in association with a transaction group ID. Here, the request for a transaction to the database (12, 22, 32) may be a request related to accessing the database (12, 22, 32), such as reading, updating, creating, or deleting data in the database (12, 22, 32).

[0045] In one embodiment, the recording module (13, 23, 33) can record the transaction in the storage (40) associated with the transaction group ID when the transaction requested to the database (12, 22, 32) is a transaction that changes the database (12, 22, 32). For example, the recording module (13, 23, 33) can store the transaction in the storage (40) associated with the transaction group ID when the transaction is any one of a data update transaction, a data deletion transaction, or a data creation transaction.

[0046] The recording module (13, 23, 33) can determine whether a transaction requested to the database (12, 22, 32) has been processed successfully and can mark the transaction determined to be an error in the storage (40). In one embodiment, the recording module (13, 23, 33) can record an error flag on the transaction determined to be an error. In one embodiment, the recording module (13, 23, 33) may be included in the system as many times as the number of applications, and in some embodiments, only one recording module (13, 23, 33) may be included in the system.

[0047] The storage (40) is a storage means that can be used publicly and may include a local storage, a network storage, etc. In the storage (40), a plurality of transactions in a hierarchical structure may be recorded associated with a transaction group ID.

[0048] FIG. 4 is a diagram illustrating a transaction with a hierarchical structure, wherein each transaction can be recorded in a storage (40) associated with a group ID. As illustrated in FIG. 4, an ID can also be assigned to the transaction and managed. The transaction ID can be assigned and recorded by a recording module (13, 23, 33).

[0049] According to FIG. 4, the transaction at the top level may be the transaction with ID#1, and the transaction at the bottom level may be the transaction with ID#3. Here, the transaction at the top level may be the transaction processed first, and the transaction at the bottom level may be the transaction processed last. Additionally, the transaction and the value of the entry to be updated or deleted may be associated and recorded in the storage (40).

[0050] FIG. 5 is a diagram illustrating another transaction with a hierarchical structure, and an error flag (ERR) indicating a transaction error may be recorded in association with the transaction, as in transaction ID #2 of FIG. 5. The error flag may be used for transaction rollback as described below.

[0051] The rollback module (50) can roll back a transaction to one or more databases (12, 22, 32) in response to a determination that an error occurred during the processing of a transaction. The rollback module (50) can identify a transaction to be rolled back based on a plurality of transactions recorded in the storage (40). In one embodiment, the rollback module (50) can identify a transaction to be rolled back based on an error flag marked on the transaction. The rollback module (50) can identify a transaction marked with an error flag and perform a rollback on said transaction. In one embodiment, the rollback module (50) can identify database identification information included in said identified transaction and perform a transaction rollback to the database (12, 22, 32) corresponding to said identification information. Additionally, the rollback module (50) can identify other transactions in a higher layer associated with the rolled-back transaction and perform a rollback on said identified other transactions.

[0052] According to the transaction processing system of the present embodiment, the recording module (13, 23, 33) monitors the transaction and records transaction-related data in the storage (40), and a rollback is performed based on the transaction recorded in the storage (40). That is, according to the present embodiment, transaction-related recording and transaction rollback are performed separately from the operation of the application (11, 21, 31). Accordingly, when it is desired to change the logic, the logic of the recording module (13, 23, 33) and the rollback module (50) can be changed without interrupting the operation of the application (11, 21, 31), so the logic change can be carried out without adversely affecting the entire system.

[0053] In addition, according to the present embodiment, since the rollback of the database (12, 22, 32) is performed based on the transaction data recorded in the storage (40), it is not dependent on the DBMS. Accordingly, it can be applied to system environments that include various types of DBMS, and thus has excellent scalability and compatibility.

[0054] FIG. 6 is a signal flow diagram for explaining a transaction processing method according to another embodiment of the present invention.

[0055] In the description referring to FIG. 6, it is assumed that application B (21) is an application located at the lowest layer.

[0056] Referring to FIG. 6, application A (11) can call application B (21) to process a requested task (S1). At this time, application A (11) can pass a transaction group ID to application B (21).

[0057] Next, application B (21) may request transaction #1 from database B (22) to distribute the above task and allow transaction #1 to be processed in database B (22) (S2). Next, record module B (23) may record transaction #1 in storage (40) in association with the transaction group ID (S3).

[0058] When a response is received from database B (22) that transaction #1 has been successfully processed (S4), application B (21) can return the processing result of transaction #1 to application A (11) (S5). Subsequently, application A (11) can request transaction #2 from database A (12) (S6). Next, record module A (13) can record transaction #2 in the storage (40) in association with the transaction group ID (S7). At this time, transaction #2 can be recorded in the lower layer of transaction #1.

[0059] An error may occur while transaction #2 is being processed by database A (12), in which case application A (11) may receive an error response for transaction #2 from database B (22) (S8). Subsequently, the record module (13, 23, 33) may record an error flag associated with transaction #2.

[0060] With transaction #2 marked with an error flag stored in the storage (40) in this manner, the rollback module (50) can access the storage (40) (S11) and identify transaction #2 marked with an error flag (S12). Upon identifying the error flag, the rollback module (50) can proceed with a process to sequentially roll back all transactions associated with the transaction group ID. First, the rollback module (50) can request a rollback for transaction #2 marked with an error flag from database B (22) (S13). If database B (22) successfully completes the rollback for transaction #2, the rollback module (50) can receive a rollback completion response from database B (22) (S14).

[0061] Next, the rollback module (50) can identify transaction #1, which is another transaction associated with the transaction group ID (S15). The rollback module (50) can request a rollback for transaction #1 from database A (12) (S16). If database A (12) successfully completes the rollback for transaction #1, the rollback module (50) can receive a rollback completion response from database A (12) (S17).

[0062] According to the present embodiment, to distribute the processing of tasks, multiple transactions are managed as a group, and if an error occurs in any of the multiple transactions, the transactions are rolled back in reverse order, thereby ensuring the consistency of the data stored in the database (12, 22, 32).

[0063] The recording module (13, 23, 33) and the rollback module (50) according to the above-described embodiment may be included in and operated in a computing device.

[0064] Hereinafter, with reference to FIGS. 7 to 10, a transaction processing method performed by a computing device including a record module (13, 23, 33) and a rollback module (50) will be described.

[0065] FIG. 7 is a flowchart of a transaction processing method according to another embodiment of the present invention.

[0066] Each step of the method illustrated in FIG. 7 may be performed by a computing device. In other words, each step of the method may be implemented by one or more instructions executed by a processor of the computing device. The first steps included in the method may be performed by a first computing device, and the second steps of the method may be performed by a second computing device. Hereinafter, the description will continue assuming that each step of the method is performed by a computing device including a record module (13, 23, 33) and a rollback module (50) described with reference to FIG. 1, provided that the entity performing each step is merely an example and the present invention is not limited by the following description, and for convenience of explanation, the entity operating some steps included in the method may be omitted from the description.

[0067] Referring to FIG. 7, a record module (13, 23, 33) included in a computing device can detect that a request for task processing is made (S110). Subsequently, the record module (13, 23, 33) can assign a transaction group ID for said task (S120). In some embodiments, an application (11, 21, 31) can assign a transaction group ID, in which case the record module (13, 23, 33) can obtain a transaction group ID from the application (11, 21, 31).

[0068] Next, when a transaction is requested to the database (12, 22, 32) by an application (11, 21, 31), the recording module (13, 23, 33) can record the transaction in the storage (40) associated with the transaction group ID (S130). That is, the recording module (13, 23, 33) can record one or more transactions associated with the transaction group ID as exemplified in FIGS. 4 and 5. Step S130 will be described in more detail with reference to FIGS. 8 and 9.

[0069] A rollback module (50) included in the computing device can access the storage (40) to determine whether there is a transaction marked as an error (i.e., having an error flag) (S140).

[0070] The rollback module (50) can roll back one or more transactions associated with the transaction group ID in response to a determination that there is a transaction marked as an error (S150). If there are multiple transactions associated with the transaction group ID, the rollback module (50) can roll back the transactions sequentially, from the transactions in the lower layer to the transactions in the upper layer. As previously explained, the transactions in the upper layer are transactions processed relatively earlier, and the transactions in the lower layer are transactions processed relatively later. Step S150 is described in more detail with reference to FIG. 10.

[0071] Meanwhile, if, as a result of the determination of step S140, there are no transactions marked as errors, the rollback module (50) can delete one or more transactions associated with the transaction group ID from the storage (40) (S160).

[0072] Hereinafter, with reference to FIG. 8, step S130 described with reference to FIG. 7 will be explained in more detail.

[0073] Referring to FIG. 8, it is possible to detect that the lowest application is called and also detect that the transaction group ID is passed from the upper transaction to the lower transaction (S131, S132). That is, the upper application can call the lower application, and the transaction group ID being passed to the called lower application can be detected by the computing device.

[0074] Next, a record module (13, 23, 33) included in the computing device can determine whether a transaction requested to the database by the called application is a type of transaction that changes the database (S133). The types of transactions that change the database may include update transactions, delete transactions, and create transactions. Here, an update transaction is a transaction that updates data contained in the database with other data, a delete transaction is a transaction that deletes data contained in the database, and a create transaction is a transaction that creates and stores new data in the database.

[0075] Next, the recording module (13, 23, 33) can record the transaction in the storage (40) in association with the transaction group ID in response to a determination that the requested transaction is a transaction that changes the database (S135). In one embodiment, the recording module (13, 23, 33) can store a previous entry value depending on the type of transaction, and the step S135 will be described in more detail with reference to FIG. 9.

[0076] Next, the recording module (13, 23, 33) monitors the transaction being processed in the database and can determine whether an error occurred when processing the transaction in the database (S136). In response to the determination that an error occurred in the transaction, the recording module (13, 23, 33) can mark the transaction as an error by recording an error flag associated with the transaction recorded in step S135 (S137).

[0077] Meanwhile, if the result of the determination in step S134 is that the requested transaction is not a transaction that changes the database, or if the result of the determination in step S136 is that the transaction has been processed normally in the database, it can be determined whether the processing of the transaction has been completed in the top-level application (S138), and if the processing of the transaction has not been completed in the top-level application, the upper application can be called (S139). In this case, the recording module (13, 23, 33) can restart the process from step S134 with respect to the called upper application and the database, and the transaction recorded thereafter is recorded in association with the transaction group ID, but can be recorded in a lower layer of the previously recorded transaction.

[0078] According to the present embodiment, a series of database transactions set as a group can be hierarchically recorded in the storage (40).

[0079] Hereinafter, with reference to FIG. 9, step S135 described with reference to FIG. 8 will be explained in more detail.

[0080] Referring to FIG. 9, the record module (13, 23, 33) can determine the type of the requested transaction (S135a).

[0081] In response to the determination that the above transaction is an update transaction (Yes in S135b), the record module (13, 23, 33) can record the value of the data entry to be updated and the update transaction together with the transaction group ID in the storage (40) (S135c). That is, if the transaction is an update transaction, the value of the data entry to be updated can be recorded together with the update transaction so that the data can be restored to its state before the update.

[0082] In response to the determination that the above transaction is a deletion transaction (Yes of S135d), the recording module (13, 23, 33) can record the value of the data entry to be deleted and the deletion transaction together with the transaction group ID in the storage (40) (S135e). That is, if the transaction is a deletion transaction, the value of the data entry to be deleted can be recorded together with the deletion transaction so that the data can be recovered before deletion.

[0083] In response to the determination that the above transaction is a creation transaction (No of S135d), the record module (13, 23, 33) can record the creation transaction in the storage (40) in association with the above transaction group ID (S135f).

[0084] According to the present embodiment, in the event that an error occurs during transaction processing, the entry value of the previous data is stored together to roll back the transaction, thereby facilitating data recovery.

[0085] Hereinafter, with reference to FIG. 10, step S150 described with reference to FIG. 7 will be explained in more detail.

[0086] Referring to FIG. 10, the rollback module (50) can access the storage (40) to identify the transaction that failed (S151). Subsequently, the rollback module (50) can perform a rollback for the identified transaction (S152). In one embodiment, the rollback module (50) can perform a rollback of the database (12, 22, 32) by checking the identification information of the database included in the transaction and requesting a rollback for the transaction to the database corresponding to the identification information. In some embodiments, the rollback module (50) can perform a rollback of the database (12, 22, 32) by providing the database with a command to restore data to the state before the command was executed, based on the command included in the transaction. For example, if the command is a create command, the rollback module (50) can provide the database (12, 22, 32) with a delete command to delete the entry value created for the create command.

[0087] Additionally, if the above transaction is an update transaction, the rollback module (50) can perform a rollback of the above transaction using the value of the update target data entry recorded in association with the update transaction. For example, the rollback module (50) can perform a rollback for the update transaction by sending an update command to the database (12, 22, 32) that updates (recovers) the entry value of the data updated according to the above update transaction to the value of the recorded update target entry.

[0088] Meanwhile, if the above transaction is a deletion transaction, the rollback module (50) can roll back the transaction using the value of the deletion target data entry recorded in association with the deletion transaction. For example, the rollback module (50) can roll back the deletion transaction by providing a creation command to the database (12, 22, 32) that regenerates the entry value of the deletion target data.

[0089] Next, the rollback module (50) can determine whether there are any transactions that have not been rolled back among the transactions recorded in association with the transaction group ID (S153).

[0090] If, as a result of the determination in step S153, it is determined that all transactions recorded associated with the transaction group ID have been rolled back, the rollback module (50) can delete the transaction group ID and the transactions associated with the transaction group ID from the storage (40) (S154).

[0091] If, as a result of the determination in step S153, there remains a transaction associated with the transaction group ID that has not been rolled back, the rollback module (50) can identify other transactions that have not been rolled back among the transactions recorded associated with the transaction group ID (S155). In one embodiment, the rollback module (50) can identify other transactions that are positioned above the rolled-back transaction. Subsequently, the rollback module (50) can perform a rollback on the identified other transactions (S156).

[0092] Meanwhile, the rollback module (50) attempts to roll back the transaction, but the rollback may not be processed normally in the database. In this case, the rollback module (50) continues to keep the transaction records stored in the storage and can later perform the transaction rollback again based on the transaction recorded in the storage (40).

[0093] According to the present embodiment, if an error occurs in any one of the transactions set as a group, a rollback is performed on all of the transactions, thereby resolving the problem of data inconsistency caused by an error in some transactions.

[0094] Hereinafter, the hardware configuration of an exemplary computing device according to some embodiments will be described with reference to FIG. 11.

[0095] FIG. 11 is an exemplary hardware configuration diagram in which a computing device can be implemented in various embodiments. A computing device (1000) according to the present embodiment may include one or more processors (1100), a system bus (1600), a network interface (1200), a memory (1400) for loading a computer program (1500) executed by the processor (1100), and a storage (1300) for storing the computer program (1500). FIG. 11 illustrates only the components relevant to the embodiment. Therefore, a person skilled in the art to which the embodiments of the present specification belong will understand that other general-purpose components may be included in addition to the components illustrated in FIG. 11.

[0096] The processor (1100) can control the overall operation of each component of the computing device (1000). The processor (1100) may be configured to include at least one of a CPU (Central Processing Unit), MPU (Micro Processor Unit), MCU (Micro Controller Unit), GPU (Graphic Processing Unit), or any form of processor well known in the art of this specification. Additionally, the processor (1100) may perform operations for at least one application or program for executing a method / operation according to various embodiments. The computing device (1000) may have two or more processors.

[0097] The memory (1400) stores various data, commands and / or information. The memory (1400) may load one or more programs (1500) from the storage (1300) to execute methods / operations according to various embodiments of the present specification. An example of the memory (1400) may be RAM, but is not limited thereto. The system bus (1600) provides communication functions between components of the computing device (1000).

[0098] The above bus may be implemented as various types of buses, such as an address bus, a data bus, and a control bus. The network interface (1200) may be connected to a communication network. The storage (1300) may store one or more computer programs (1500) non-temporarily. The storage (1300) may be configured to include non-volatile memory such as flash memory, a hard disk, a removable disk, or any type of computer-readable recording medium well known in the art to which the embodiments of this specification belong.

[0099] A computer program (1500) may include one or more instructions in which methods / operations according to various embodiments of the present specification are implemented. When the computer program (1500) is loaded into memory (1400), a processor (1100) may perform methods / operations according to various embodiments of the present specification by executing the one or more instructions. The computer program (1500) may include instructions for the method described with reference to FIGS. 3 through 10. In one embodiment, the computer program (1500) may perform instructions for the operation of a write module (13, 23, 33) and instructions for the operation of a rollback module (50).

[0100] The above computer program (1500) may include instructions for performing operations such as: recording a first transaction requested by a first application among a plurality of applications in association with a transaction group ID; recording a second transaction requested by a second application called by the first application among the plurality of applications in association with the transaction group ID; rolling back the second transaction against the second database in response to a determination that an error occurred during the processing of the second transaction; identifying the first transaction based on the transaction group ID; and rolling back the first transaction against the first database.

[0101] Various embodiments of the present invention and effects according to those embodiments have been described with reference to FIGS. 1 to 11. The effects according to the technical concept of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by a person skilled in the art from the description below.

[0102] The technical concept of the present invention, as described so far with reference to FIGS. 1 to 11, can be implemented as computer-readable code on a computer-readable medium. The computer-readable recording medium may be, for example, a removable recording medium (CD, DVD, Blu-ray disc, USB storage device, removable hard disk) or a fixed recording medium (ROM, RAM, computer-equipped hard disk). The computer program recorded on the computer-readable recording medium may be transmitted to another computing device via a network such as the Internet and installed on the other computing device, thereby being used on the other computing device.

[0103] Although it has been described above that all components constituting the embodiments of the present invention are combined as one or operate in combination, the technical concept of the present invention is not necessarily limited to such embodiments. That is, within the scope of the objectives of the present invention, all components may be selectively combined in one or more ways to operate.

[0104] Although operations are depicted in a specific order in the drawings, it should not be understood that the operations must be executed in the specific order depicted or in a sequential order, or that all depicted operations must be executed to obtain the desired result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various configurations in the embodiments described above should not be understood as a necessary separation, and it should be understood that the described program components and systems can generally be integrated together into a single software product or packaged into multiple software products.

[0105] Although embodiments of the present invention have been described above with reference to the attached drawings, those skilled in the art will understand that the present invention may be implemented in other specific forms without altering the technical concept or essential features thereof. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. The scope of protection of the present invention shall be interpreted by the claims below, and all technical concepts within the equivalent scope shall be interpreted as being included within the scope of rights of the technical concept defined by the present invention.

Claims

Claim 1 A method for processing a series of database transaction groups sequentially requested by a plurality of applications, comprising: a step of recording a first transaction requested by a first application among the plurality of applications to a first database in association with a transaction group ID; a step of recording a second transaction requested by a second application called by the first application among the plurality of applications to a second database in association with the transaction group ID, wherein the second transaction is recorded in a lower layer of the first transaction; a step of recording an error flag in association with the ID of the second transaction in response to a determination that an error occurred during the processing of the second transaction; a step of rolling back the second transaction against the second database based on the error flag associated with the ID of the second transaction; a step of identifying the first transaction associated with the transaction group ID and in a higher layer of the second transaction; and a step of rolling back the first transaction against the first database, wherein the first database and the second database are physically or logically distinguishable from each other. Claim 2 delete Claim 3 A series of database transaction processing methods according to claim 1, wherein when the second application is called by the first application, the transaction group ID is transmitted to the second application by the first application. Claim 4 A series of database transaction processing methods according to claim 1, further comprising: a step of recording a third transaction requested to a third database by a third application called by a second application among the plurality of applications in association with the transaction group ID; a step of rolling back the third transaction to the third database in response to a determination that an error occurred during the processing of the third transaction; a step of identifying the second transaction and the first transaction based on the transaction group ID; and a step of sequentially rolling back the second transaction and the first transaction. Claim 5 In claim 1, the operation of recording a first transaction requested in the first database is a series of database transaction processing methods triggered by the first database. Claim 6 A series of database transaction processing methods according to claim 1, wherein the step of recording a first transaction requested in the first database in association with a transaction group ID includes, if the first transaction is a data update transaction, the step of recording the value of a data entry to be updated prior to the update by the first transaction, and the step of rolling back the first transaction against the first database includes the step of rolling back the first transaction using the recorded value of the data entry to be updated. Claim 7 A series of database transaction processing methods according to claim 1, wherein the step of recording a first transaction requested in the first database in association with a transaction group ID includes, if the first transaction is a data deletion transaction, the step of recording the value of a data entry to be deleted prior to deletion by the first transaction, and the step of rolling back the first transaction against the first database includes the step of rolling back the first transaction using the recorded value of the data entry to be deleted. Claim 8 A series of database transaction processing methods according to claim 1, wherein the determination that an error occurred during the processing of the second transaction is a determination based on data recorded in a shared storage. Claim 9 A series of database transaction processing methods according to claim 1, further comprising the step of deleting the record of the first transaction and the record of the second transaction in response to a determination that the processing of the first transaction and the second transaction has been successfully completed. Claim 10 A series of database transaction processing methods according to claim 1, further comprising the step of deleting the record of the first transaction and the record of the second transaction in response to a determination that the rollback processing of the second transaction and the first transaction has been successfully completed. Claim 11 A series of database transaction processing methods according to claim 1, further comprising the step of maintaining the record of the first transaction and the record of the second transaction in response to a determination that an error occurred during the rollback processing of the second transaction or the first transaction. Claim 12 delete Claim 13 One or more processors; memory for loading a computer program executed by said processors; and storage for storing said computer program, wherein the computer program comprises: an operation of recording a first transaction requested by a first application among a plurality of applications to a first database in association with a transaction group ID; an operation of recording a second transaction requested by a second application called by the first application among the plurality of applications to a second database in association with the transaction group ID, wherein the second transaction is recorded in a lower layer of said first transaction; an operation of recording an error flag in association with the ID of said second transaction in response to a determination that an error occurred during the processing of said second transaction; an operation of rolling back said second transaction to said second database based on the error flag associated with the ID of said second transaction; and an operation of identifying said first transaction which is in a higher layer of said second transaction and associated with the transaction group ID. A computing device comprising instructions for performing an operation to roll back the first transaction targeting the first database, wherein the first database and the second database are physically or logically distinct from each other. Claim 14 A computer-readable non-transient recording medium comprising instructions, wherein when the instructions are executed by a processor, the processor causes the processor to record a first transaction requested by a first application among a plurality of applications to a first database in association with a transaction group ID; among the plurality of applications, a second transaction requested by a second application called by the first application to a second database in association with the transaction group ID, wherein the second transaction is recorded in a lower layer of the first transaction; in response to a determination that an error occurred during the processing of the second transaction, an error flag is recorded in association with the ID of the second transaction; based on the error flag associated with the ID of the second transaction, the second transaction is rolled back against the second database; and the first transaction is identified in a higher layer of the second transaction and is associated with the transaction group ID. A computer-readable non-transient recording medium that performs operations including the step of rolling back the first transaction against the first database, wherein the first database and the second database are physically or logically distinct from each other.

Images