TRANSACTION CONTINUITY Transaction, or application, continuity in it's most general sense is the shielding of errors from upper layers

in the transaction, or application, stack thus providing perceived continuous and unambiguous transaction processing. This is not a new problem and attempts to address this at various levels and scopes of the stack have been made in the past (from catching an exception in application source code to disaster recovery across physical sites). Although certain areas of the problem have been openly specied, such as two-phase commit consensus protocol, eg., many others have not and most often proprietary solutions are employed at some discrete evel(s). The overall relationship for an end to end continuity solution exists only in a number of patterns and invariably no one applies to all particularly in the common, non-idempotent case. These patterns include retry, various state and context restoration, outcome query, compensation, and so on. The more localized the problem can be isolated, the more performant the continuity, while inversely the grander the scope, the more contextual and less risky the method becomes though the greater the performance and timing cost. As the proximity of the problem moves down the stack toward the data, the problem lends itself to being more localized. An attempt to analyze continuity can be taken by addressing the concerns tier by tier starting from the bottom, at the end of the request ow, ie the data, and working up the stack to the end-user. Hardware, network, and other considerations are to be taken into account, however, the software stack proves a means for the starting point of the discussion particularly as it is in most direct logical contact with the transaction request ow itself. The data tier is generally the most durable and stable source of truth in the architecture, however, the appropriate data must be persisted efciently and reliably and it must be highly available and accessed in the correct contextual state in order to provide continuity in the face of failure in this tier. One type of failure is process or storage crash or corruption, where various forms of recovery data are required, the quantity of which often increasing with the continuity quality of service requirements. Another type of failure lies in the interaction with the client, such as network failure from a middle tier connection, where requirements include establishment of new connections, the reinitialization of non-transactional context on these connections and any environment, cursor and logic positioning, nested routines (potentially transactions) in data tier logic, the passing of time, etc. These type of failures tend to require a cooperation between the data tier and middle tier to provide the ability to replay the work that was underway during the failure or query the outcome of these in-ight operations in order to provide correct and sufcient continuity at these layers. The middle tier has access to the greatest amount of contextual information in the stack (requests and context from the presentation layer ow into it and data access ows out of it), and so lends itself to continuity at a greater scope. Indeed the middle-tier requires this breadth of contextual information as the scope and variants of the continuity necessary to consider also increase. In the face of failure communicating to the data layer, middle tier must be able to reinitialize both the connection state, etc. necessary for consistency when interacting with the data tier but also reinitialize application contexts such as global shared state and presentation tier session state (eg http requests and responses) in order to conduct work scope replays, outcome queries, compensating activities and other patterns that provide for continuity. As with the data tier, the middle tier must account for process crash entailing failover, replication, and other high availability services while providing enough context in these scenarios to provide continuity in addition to fundamental resource data recovery. As with the data and middle tier, the middle and presentation tier work in concert to provide continuity. The presentation tier can be augmented to bring continuity all the way to the end-user such as the browser or other interface. Various functionality available in the modern browser itself allows for the avoiding of duplicate non-idempotent requests, local transactionality, the handling of failover and load balancing considerations via context present on the requests made to the middle tier, and so on. The presentation tier can also react based on the response from the middle tier and shield the end user from ambiguity and error. When working in tandem with the middle tier it is also possible to provide transactional quality allowing the request, response, and any necessary state to

be preserved such that any aspect of the request ow from presentation to middle to data tier may experience any failure at any time and combination and the continuity solution may provide transparency of such failure to the end user. It is an extremely extensive task to provide true end to end transaction continuity particularly as there are barriers to many solutions due to the fact that applications themselves are designed according to different models and often outside the best practices and standards of those models thereby entailing aspects that are resilient to may continuity patterns. These include items ranging from basic counters that may not be reset or decremented, global or system states, logging, various overall hardware and network system considerations, and so on. Providing transaction continuity in one form or another entails applying transactional guarantees across states and procedures that are not traditionally transactional. Transactional patterns for these cases often allow for relaxed ACID properties. There are existing technologies that do cover certain aspects of continuity (such as reliable messaging), many older patterns that can be applied to provide certain other continuity characteristics (such as queued transaction processing), and the decoupled, service contract based, location-agnostic nature of the cloud actually lends itself to continuity protocols in many ways. Taken all together these capabilities may handle requirements ranging from the tightlycoupling locking case to the more non-traditional transactional resources involved in continuity.