Abstract:
Incorporation of a collateral process as a participant in a transaction is made possible by a method and system in accordance with the present invention. Typically, after the transaction is initiated, the collateral process is called and then is registered as a participant,in the transaction. A prepare signal is sent to each registered collateral process when end stage of the transaction is reached. Then, a ready signal is received from the collateral process if the collateral process is completed successfully; and an abort signal is received from the collateral process if the collateral process does not complete successfully or a violation is detected. If a ready signal is received, a commit record is written to a log, and a commit signal is sent to each registered collateral process. In response to the commit signal, a forgotten signal is received from each registered collateral process.

Description:
BACKGROUND OF THE INVENTION 
     The invention relates generally to a transaction processing system, and more particularly to incorporating collateral activity as a participant in a transaction. 
     A transaction most often is defined as an explicitly delimited operation, or set of related operations, that change or otherwise modify the content of an information collection (e.g., database) from one consistent state to another. Changes are treated as a single unit in that all changes of a transaction are formed and made permanent (the transaction is “committed”) or none of the changes are made permanent (the transaction is “aborted”). If a failure occurs during the execution of a transaction, resulting in the transaction being aborted, whatever partial changes were made to the collection can be undone so that the information collection remains in a consistent state. 
     Often, it is desired that certain activity be associated with a transaction, but performed after the transaction is completed. For example, an application executing a transaction may desire to verify that the transaction is consistent under certain policy guidelines or rules. Consider a transaction processing system structured to maintain a company database that includes information respecting the company&#39;s employees, including payroll. Consider a change to the payroll information for a particular employee such as implementing a raise in the employee&#39;s salary. Then, the payroll information change is checked or verified to see that it was made pursuant to company guidelines. In the past that payroll change would then be made and committed (made persistent) before the change (raise in salary) is checked. If such guidelines were exceeded, the change is typically undone. 
     While effective, calling upon such collateral activity after the transaction has been completed can be time-consuming, particularly if the collateral activity or check requires that the preceding change be withdrawn. 
     Accordingly, there is a need to incorporate collateral activity within the bounds of a data processing transaction before the transaction completed and make persistent. 
     SUMMARY OF THE INVENTION 
     The present invention provides, in the context of a transaction, a resource that performs collateral activity (i.e., activity not directly related to a change of an information collection), allowing it for example to participate in the transaction as a “voting” member. Thus, the collateral activity can participate in the decision of whether or not the change should be made. 
     Broadly, according to the present invention, when an application process initiates a transaction, it can also employ a collateral process to perform work that is not directly related to a change of state in the information collection (hereinafter “database”) but is able to participate in that transaction. The invention is employed in the context of transaction management provided by a transaction monitor facility (TMF) operable to protect the integrity of user data maintained in the database, particularly when the state of that database is changed. According to the invention, the collateral process may be called by an application as part of a transaction. When called, the collateral process can request participation in the transaction as a voting member by making a call to TMF_Export, an application programming interface (API). The call will provide the called API with the identities of the calling process and the transaction in which participation is desired. Among the tasks performed by the API is one that functions to “register” a calling process with an identified transaction. A registered process allows it to become a participant in the transaction and can vote in the two-phase commit protocol performed when the end transaction aspect is reached. 
     Typically, the transaction is monitored and tracked by a TMF, and preferably concludes using a two-phase commit protocol. Typically also, the TMF initiates the conclusion of a transaction by sending a “Prepare” signal. In reply, registered participants of the transaction return “Ready” signals, indicating that they made the necessary preparations to make the change persistent. When the collateral process receives the “Prepare” signal, it will perform its collateral activity. When that collateral activity is complete, the collateral process will either return a “Ready” signal, indicating that the collateral activity completed successfully, or returned an “Abort” signal, indicating that the collateral activity did not complete successfully or that the change in the database being made by the transaction violated some policy or guideline. 
     A conventional transaction control block (TCB) data structure is formed when the transaction is initiated. The TCB data structure is basically a public container, with some private fields, that provides a description of the associated transaction. The TCB data structure includes the identity of each participant in the transaction, thereby identifying the resources that will receive the “Prepare” signal when the end transaction stage is reached. Therefore, in addition to those participants of which the TMF normally has cognizance, i.e., those whose operation will result in the change of the database, a process may join as a participant by calling the TMF_Export function. That function will, in turn, notify TMF that the calling process desires participation, and TMF will write the identity of the calling process to the TCB data structure of the associated transaction. 
     A number of advantages are achieved by the present invention. By including collateral activity in the context of the transaction, that collateral activity can be performed in parallel and concluded with the transaction to improve efficiency and linearity of operation. 
     In addition, should the collateral activity so indicate, undoing the transaction at the behest of the collateral activity can be performed at a stage before the change of state of the database is made persistent. 
     These and other aspects and advantages of the invention will become apparent to those skilled in the art upon a reading of the following detailed description of the invention, which should be taken in conjunction with the accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 illustrates a multiple process transaction processing system for employing the present invention; 
     FIG. 2 illustrates a transaction control block (TCB) data structure, including the identity of participating resources in the associated transaction; and 
     FIG. 3 is a flow diagram illustrating the steps used to employ the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     Turning now to the figures, and for the moment specifically FIG. 1, there is illustrated a transaction processing system, designated with the reference numeral  10 . As FIG. 1 shows, the transaction processing system  10  is formed from a number of individual central processing units (CPUs)  12 ,  12   a ,  12   b , . . .  12   n )), and a storage system (e.g. disk unit)  16  ( 16   a ,  16   b ,  16   c ) interconnected by a system area network (SAN)  18  for communicating data therebetween. Although the transaction processing system  10  is illustrated in the form of a multiprocessor architecture, the present invention need not employ multiple processors; rather, the invention can be used on a single processor unit. 
     If a multiprocessor architecture is used, preferably the transaction processing system  10  will have an architecture along the lines of that disclosed in U.S. Pat. No. 5,751,932, incorporated herein by reference to the extent necessary. As such, each of the CPUs  12  will have direct access, through the SAN  18 , to any of the disk storage units  16 . However, only that CPU  12  having the appropriate driver process for the particular disk storage unit  16  actually has effective access. Thus, for example, the CPU  12   a  has resident a disk process (DP)  20   a  for controlling data transfers between the CPU  12   a  and, for example, the disk storage unit  16 A. Similarly, a disk process  20   n , resident on the CPU  12   n , may provide the control for data transfers between the CPU  12   n  and the disk storage unit  16   b . Of course, other processes may control other resources (e.g., disk storage unit  16   c ), but are not shown in order that the figure not be unduly complicated. 
     For transaction processing, the transaction processing system  10  will include a distributed transaction monitor facility (TMF) having a TMF component  24  resident on each CPU  12 . In addition, a transaction monitor process (TMP)  26  will be resident on one of the CPUs  12 —here, CPU  12   a . The TMF components  24  operate to coordinate and track a transaction. At the conclusion of a transaction, the TMP  26  is called upon to write a record of the change to, for example, an audit log. When a transaction is started on one CPU  12 , the CPU is designated the “beginner” CPU, and the TMF component  24  on the beginner CPU is herein referred to as the “beginner” TMF component. If the transaction involves a process resident on another CPU  12 , that other process (as do the CPU  12  and its associated TMF component  24 ) becomes a “participant” of the transaction, and subordinate to the beginner TMF component  24  on the beginner CPU  12 . 
     Transactions are initiated by applications desiring to change the state of the information collection or database maintained by the transaction processing system  10 . Typically, that state is in persistent form on the secondary storage utilized by the system, such as the disk storage unit  16 . An application will begin a transaction with a “Start Transaction” call to the local TMF component  24 , providing information necessary for the TMF component to monitor and track the transaction. When that call is received by the TMF component  24 , the TMF component (now, the beginner TMF component) will form a transaction control block (TCB) data structure  30  which will contain the information needed by the beginner TMF component  24  for monitoring and tracking the transaction, including the identity or identities of any resource managers to be used in the transaction. This is used, depending upon the protocol used to make any changes of state of the database persistent, to coordinate the end operation. Preferably, the transaction will conclude employing the conventional two-phase commit (2PC) protocol. Briefly, according to this protocol, a transaction concludes two phases: A first phase in which the beginner TMF component  24  sends a “Prepare” Signal to all participating subordinates (e.g., processes) indicating that it is time for them to prepare to make any changes to the state of the database in which they are involved permanent. If the subordinate is able to ready itself, it will respond (through its associated component  24 ) with a “Ready” signal. When Ready signals are received from all participating subordinates, the beginner TMF component  24  will then “commit” the transaction by first requesting the TMP  26  to write a commit record to an audit log, and then by sending a “Commit” signals to the participating subordinates. The subordinates will then conclude their work, reply with a “Forgotten” signal, indicating that everything went properly. 
     There are a number of variations in this protocol, for example, presumed abort or presumed nothing, as is conventional, but these variations are not relevant to the understanding of the present invention. 
     As an example, and referring to the flow diagram  60  of FIG. 3 assume that an application  40  (FIG. 1) initiates a transaction from CPU  12   c . Assume further that the application  40  will require the services of the CPUs  12   a , and  12   n , i.e., disk storage units  16   a ,  16   b  managed by the disk processes  20   a  and  20   n , respectively. In step  62 , the application  40  will first issue a “Start Transaction” call to the local TMF component  24 , making it the beginner TMF component for the transaction, and providing the TMF component with information as to the transaction. The beginner TMF component  24 , at step  64 , will prepare the TCB data structure  30  for that transaction. 
     The application  40  will, at step  68 , then send request messages (RQST- 1 , RQST- 2 ) to the processes to be used (disk processes  20   a ,  20   n ). When the enlisted process (e.g., disk process  20   a ) receives the request (RSQT- 1 ), which contains information identifying the transaction, it will inform its local TMF component  24 , who in turn notifies the coordinator beginner TMF component on CPU  12   b , which writes that information to the TCB data structure  30 . Thus, the requests sent to the disk processes  20   a ,  20   n  will cause their identities to be written to the TCB data structure  30  at fields  30   a  and  30   b , respectively. Once the work of the application  40  is done (i.e., all requests sent and “Done” messages received back from the enlisted resources such as DP 1  and DP 2 ), the application  40  will, at step  74 , make an End Transaction call to cause the beginner TMF component  24 C to, at step  76 , initiate the 2PC protocol to either fix (make persistent) the change effected to the database managed by the system  10  or to abort. 
     Assume now that some collateral activity is needed to verify the requested change to the state of the database. Normally, this collateral activity would then be called by the application  40  after the transaction has proceeded through the 2PC protocol and the change is made. If that verification indicates that the change violates certain policy rules, it must be undone. To obviate that situation, the present invention is provided. 
     According to the present invention, an application programming interface (API)  50  (shown in FIG. 1 as residing on CPU  12   b ) is provided to implement one or more predetermined policy rules. API  50  is an application specific process, called within the context of the particular transaction started by the application  40 . Thus, with the requests RQST- 1  and RQST- 2  sent to the disk processes DP 1  and DP 2 , respectively, to enlist their services in the transaction (step  68 ), the application  40  will also make a request (RQST- 3 ) of the API  50 . When the request is made, the application  40  will supply the particulars that are to be measured against the policy rules and verified or not verified. However, the API  50  needs voting participating in the transaction so that it can abort the transaction if a particular policy rules it is verifying are violated. Accordingly, in step  70 , the API  50  is structured to make a call (TMF_EXPORT) to its local TMF component  24   b , supplying the identity of the caller, API  50 , and the identification of the transaction (supplied the API  50  by the application  40 ). 
     The TMF_EXPORT call operates to “register” the API  50  with the transaction by messaging the beginner TMF component  24 C to write the identification of the API  50  to the TCB data structure  30  corresponding to the transaction. Thereby, API  50  is registered as a participant in the transaction. Thus, the TCB data structure  30  will now contain the identities of the participants of the transaction as disk processes  20   a ,  20   n  at fields  30   a ,  30   b , and API  50  at field  30   c.    
     When the application  40  has completed its work, it will call End Transaction as before (step  74 ). This will cause the TMF component  24  on the beginner CPU  12   c  to initiate the  2 PC protocol (step  76 ) by broadcasting “Prepare” signals to all CPUs  12 . Those CPUs  12  having transaction participants, i.e., the CPUs  12   a  (disk process  20   a ),  12   b (API  50 ), and  12   n  (disk process  20   n ), will through their respective TMF components  24 , will notify the participants. Thus, when the API  50 , since it is now a participant, receives the Prepare signal, it will perform its specified function to verify, if that is its function, the consistency of the change according to predetermined policy rules. If that verification finds that the change to the state of the database is consistent with those policy rules, the API  50  will reply to the inner TMF component  24  of the beginner CPU  12   c  a Ready signal, as will the disk processes  20 , if they have not encountered any faults and are prepared to make the change persistent. The TMF component  24  of the beginner CPU  12   c  can then commit the change as described above. 
     If, on the other hand, the verification or other collateral activity performed by the API  50  indicates that the requested change violates some predetermined rule, the API  50  will return an Abort signal to the TMF component  24  on the beginner CPU  12   c , causing the TMF component  24  to abort the transaction, and roll back the change in conventional fashion so that it is not effected. 
     The specific embodiments detailed herein are by way of example and not limitation. Also, modifications and substitutions will be readily apparent to one of ordinary skill in the art on reading the background and invention description above. For example while those resources or processes directly involved in a transaction to change the state of an information collection, such as the disk processes DP 1  and DP 2 , are usually “recoverable,” those resources or processes not involved in that change of state, i.e., collateral activity such as provided by API  50 , need not be recoverable and can, in fact be “volatile.” A volatile resource is one for which no recovery is necessary after the system crashes, as is necessary (and conventional) for recoverable resources. Thus, there is no need to keep a record of a volatile resource after a commit signal is sent by a beginner TMF component—as is done for recoverable resources. Accordingly, the scope of the invention is to be determined by the metes and bounds of the claims which follow.