Adaptive method and software architecture for efficient transaction processing and error management

Abstract

A new type of transaction manager is disclosed that provides a unique set of methods and components for efficient transaction processing, error management, and transaction recovery. The combination of these methods and components are applicable to a wide range of business and technical scenarios that do not lend themselves to traditional transaction processing methods, permitting a degree of automation and robustness hitherto impossible. The methods extend and generalize the traditional transaction properties of atomicity, consistency, isolation, and durability.

182 . A method for efficient transaction processing and error management implemented as an Adaptive Transaction Manager (‘ATM’), the method being extensible to multiple business entities (related or independent) and extensible to complex transactions, said method comprising: 
 a coordinated set of sub-methods, extensible to and instantiable upon a distributed network of computers, each particular sub-method and any set thereof also being usable by either a unitary database management system or a distributed database management system, said sub-methods comprising steps for: 
 implementing transaction consistency points;  
 implementing transaction relaying;  
 implementing corrective transactions;  
 implementing lookahead-based resource management; and,  
 implementing dependency-based concurrency optimization.  
   
     
     
         183 . A general-purpose computer incorporating specific hardware and software for manipulating at least one database when processing at least one transaction, wherein said specific hardware and software comprise: 
 means for implementing transaction consistency points;    means for implementing transaction relaying;    means for implementing corrective transactions;    means for implementing lookahead-based resource management; and,    means for implementing dependency-based concurrency optimization.    
     
     
         184 . A general-purpose computer that includes software, dynamic and stable memory, and logical processing hardware, programmed for manipulating at least one database when processing at least one transaction and manipulating steps in at least one transaction, comprising: 
 means for manipulating the software, logical processing hardware, and dynamic and stable memory, to designate a set of current data values for any part of the data in the database and any particular step in a transaction, as a transaction consistency point;    means for manipulating the software, logical processing hardware, and dynamic and stable memory, to select at least one set of current data values for any part of the data in the database, and to manipulate any set of particular steps in at least two transactions, to effectuate transaction relaying;    means for manipulating the software, logical processing hardware, and dynamic and stable memory, upon detection of an error condition, to selectively effectuate implementation of at least one corrective transaction;    means for manipulating the software, logical processing hardware, and dynamic and stable memory, to automatically implement optimization of the use of said logical processing hardware and dynamic and stable memory through altering the steps in a definition of said transaction using lookahead-based resource management; and,    means for manipulating the software, logical processing hardware, and dynamic and stable memory, to automatically manipulate the steps of said transaction and software, and automatically implement optimization of said logical processing hardware and dynamic and stable memory, for the processing of said transaction, through implementation of dependency-based concurrency optimization.    
     
     
         185 . A method as in  claim 182  wherein the ATM is applied to at least one member of a set of business problems comprising telecommunications, retail, inventory, funds transfer, message repair, financial transactions, government fiats, negotiation, asset exchanges, distributed business transactions, electronic commerce, business process automation, business-to-business exchanges, business integration, insurance, and billing.  
     
     
         186 . A method as in  claim 183  further comprising using transaction relaying to implement non-flat transactions.  
     
     
         187 . A computerized method for both efficient transaction processing implemented as a defining feature of an Adaptive Transaction Manager (‘ATM’) and for determining a first transaction, said method comprising: 
 (a) identifying a first set of consistency conditions on a first set of data elements, comprising at least a first consistency condition;    (b) identifying a second set of consistency conditions on a second set of data elements, comprising at least a second consistency condition, without requiring the second set of consistency conditions to be distinct from the first set of consistency conditions;    (c) associating the first set of consistency conditions with a first set of operations comprising at least one operation on at least one element from the combined first set of data elements and second set of data elements, the first set of operations having an initial state and a final state, said final state being: 
 represented by the second set of data elements;  
 required to satisfy the second set of consistency conditions;  
 reached upon successful termination of the first set of operations;  
 consistent with the second set of consistency conditions;  
 computed from both the initial state and any parameters; and,  
 resulting from unexceptional execution;  
   (d) specifying the initial state of the first set of operations as being the first transaction's initial state;    (e) performing at least one operation of the first set of operations;    (f) specifying the final state of the first set of operations as being the first transaction's final state; and,    (g) committing the first transaction automatically after determining that the first transaction's final state satisfies the second set of consistency conditions.    
     
     
         188 . A method as in  claim 187  for implementing a first implicit transaction as the first transaction wherein an explicit transaction directive to begin the first transaction does not precede any operation in the first set of operations as any part of the first transaction's initial state, an explicit transaction directive to end the first transaction does not follow the first set of operations' final operation as any part of the first transaction's final state, and every operation necessary to initiate and to end the first transaction is performed automatically.  
     
     
         189 . A method as in  claim 187  further comprising guaranteeing that the first transaction satisfies at least one member of a set of transaction properties comprising atomicity, consistency, isolation, and durability.  
     
     
         190 . A method as in  claim 188  wherein the step of committing the first implicit transaction guarantees the property of atomicity by performing the step if and only if each and every operation of the first set of operations is both successful and representable as a connected set of state transitions resulting from the first set of operations, said first set of operations being fully determined at the first transaction's final state.  
     
     
         191 . A method as in  claim 187  further comprising guaranteeing at least partially the property of consistency by: 
 defining a class of consistency conditions prior to reaching the first transaction's initial state; and,    determining that the first set of consistency conditions belongs to the class of consistency conditions.    
     
     
         192 . A method as in  claim 188  further comprising guaranteeing at least partially the property of consistency by: 
 defining a class of consistency conditions prior to the first implicit transaction's final state being reached; and,    determining that the second set of consistency conditions belongs to the class of consistency conditions.    
     
     
         193 . A method as in  claim 187  wherein the step of committing the first transaction guarantees the property of consistency by performing the step if and only if: 
 the first transaction's initial state is determined to satisfy some set of consistency conditions belonging to a first class of consistency conditions defined prior to the first transaction reaching the first transaction's initial state; and,    the first transaction's final state is determined to satisfy some set of consistency conditions belonging to a second class of consistency conditions defined prior to the first transaction reaching the first transaction's final state;    wherein the first class of consistency conditions and the second class of consistency conditions may be one and the same class of consistency conditions.    
     
     
         194 . A method as in  claim 187  further comprising guaranteeing the property of isolation and incorporating the steps of: 
 identifying a first sharable resource as being a portion of a first intermediate state of the first transaction;    identifying at least a second transaction that has not terminated;    determining that the portion of the first intermediate state of the first transaction is not inconsistent, non-contradictory, and non-conflicting with the second transaction;    controlling sharing of the first sharable resource among the first transaction and the second transaction, including access by the second transaction to the first sharable resource, based on the step of determining.    
     
     
         195 . A method as in  claim 194  wherein the step of determining further comprises: 
 identifying a common history of the first sharable resource that is consistent with both the first transaction's definition and history and with the second transaction's definition and history, said common history being functionally equivalent to a partially ordered set of states and state transitions of the first sharable resource, each said state transition corresponding to an operation capable of generating that state transition from one of said states.    
     
     
         196 . A method as in  claim 194  wherein the step of controlling further comprises: 
 precluding sharing of the first sharable resource among the first transaction and the second transaction when both the first transaction and the second transaction could not have accessed a common initial state of the first sharable resource given the known states of the first sharable resource, when those states existed and when the first transaction and the second transaction began.    
     
     
         197 . A method as in  claim 194  further comprising: 
 rewriting at least one rewritable operation of any of the first transaction, the second transaction, and a second implicit transaction so as to be recorded as having been executed in the context of a different transaction;    executing the at least one rewritable operation in the context of the different transaction; and,    using the result of said step of rewriting as component in a recoverable record of all operations and states logically necessary to maintain the common history of the first sharable resource.    
     
     
         198 . A method as in  claim 197  wherein the different transaction is a new implicit transaction and the original, pre-rewriting result of said rewritable operation is then not committed in the context of any of the first transaction, the second transaction, and the second implicit transaction.  
     
     
         199 . A method as in  claim 187  wherein the property of durability is guaranteed by ensuring that the first transaction's final state is recoverable insofar as the first transaction's final state has any effect on transaction history at the time of recovery.  
     
     
         200 . A method as in  claim 199  wherein the first transaction's final state is recovered by recomputing the first transaction's final state.  
     
     
         201 . A method as in  claim 187  further comprising: 
 selecting a first alternative final state from among a set of alternative final states;    basing the selection on at least one member of a set of acceptability critera comprising any of measures of risk, measures of opportunity, measures of cost, and measures of benefit; and,    ensuring that the final operation within the first transaction will yield the selected alternative final state.    
     
     
         202 . A method as in  claim 187  further comprising: 
 stating a first goal;    deriving a first goal-oriented transaction's definition by selecting from a second set of operations a sequence of transitions from the first goal-oriented transaction's initial state to the first goal-oriented transaction's final state; and,    determining that said first goal-oriented transaction's final state satisfies the first goal; and,    executing the first goal-oriented transaction.    
     
     
         203 . A method as in  claim 187  further comprising maintaining in durable storage at least one member of a set of audit log enhancements, said set of audit log enhancements comprising identification of an acceptable state, identification of a mistaken state, identification of a compensating transaction, identification of a corrective transaction, and identification of a final acceptable state.  
     
     
         204 . A method as in  claim 188  further comprising: 
 maintaining in durable storage at least one member of a set of audit log enhancements comprising identification of an acceptable state, identification of a mistaken state, identification of a compensating transaction, identification of a corrective transaction, identification of a final acceptable state, and, identification of the first implicit transaction.    
     
     
         205 . A method as in  claim 203  wherein the at least one member of a set of audit log enhancements is maintained in an audit trail.  
     
     
         206 . A method as in  claim 204  wherein the at least one member of a set of audit log enhancements is maintained in a transaction log.  
     
     
         207 . A general-purpose computer incorporating specific hardware and software for manipulating at least one database when processing at least one transaction, wherein said specific hardware and software comprise: 
 Parser means for any of the set of interpreting and compiling transaction definitions;    Repository means for storing, retrieving, and modifying elements of transaction metadata, including at least one of transaction definitions, consistency conditions, sets of consistency conditions, classes of consistency conditions, dependencies, publication/subscription definitions, audit log enhancements, and transaction resources;    Repository Manager means for coordinating all stored information, including dependencies, transaction definitions, associations, sets of consistency conditions, classes of consistency conditions, audit log enhancements, consistency categories, and subscriptions;    Consistency Manager means for detecting and verifying transaction consistency points, verifying consistency of transaction and resource histories, and defining implicit transactions;    Dependency Manager means for interpreting dependency directives, detecting dependencies, determining transaction and resource histories, deriving sequences of operations to attain specified states as goals, identifying consistent groups based on dependencies and asserting the corresponding consistency points;    Resource Manager means for implementing transaction relaying and lookahead-based resource management, accessing and updating resources, allocation management, scheduling, resource isolation, maintaining cache, maintaining other resource constraints, detecting resource requirements, implementing resource management directives, and providing resource management directives to the Restructuring Processor;    Correction Processor means for implementing corrective transactions, correlating abnormal conditions and consistency points, and by any set of using direct association and using any of consistency condition categories and classes of consistency conditions, performing any of discovering, optimally selecting, and creating a corrective transaction and submitting the corrective transaction to the Execution Manager;    Restructuring Processor means for rewriting transactions;    Isolation Manager means for guaranteeing isolation of resources and transactions;    Publication/Subscription Manager means for processing publication and subscription definitions, detecting publication events, and notifying appropriate subscribers of publication events;    Execution Manager means for processing transactions, allocating and deallocating transaction contexts, passing directives and instructions to the appropriate ATM components, and orchestrating transaction scheduling, commit, rollback, and rollforward; and,    Resource Scheduler means for implementing dependency-based concurrency optimization.