Compensating Transaction pattern (transaction correction mode)

Undo the work performed by a series of steps, which together define an eventually consistent operation, if one or more of The steps fail. Operations that follow the eventual consistency model is commonly found in cloud-hosted applications that implement Compl Ex business processes and workflows.

Undo the work performed by a series of steps, together defining a final, consistent action if one or more steps fail. In cloud-hosted applications, the implementation of complex business and workflow processes is typically followed by a final consistency model. Context and problem background and issues

Applications running in the cloud frequently modify data. This data is spread across an assortment of the data sources held in a variety of geographic locations. To avoid contention and improve performance in a distributed environment such as this, an application should not attempt t o Provide strong transactional consistency. Rather, the application should implement eventualconsistency. In the this model, a typical business operation consists of a series of autonomous steps. While these steps is being performed the overall view of the system State could be inconsistent, if the operation has Completed and all of the steps has been executed the system should become consistent again.

Applications running in the cloud often modify the data, which may be scattered across geographically sourced data sources. To avoid competition and improve performance, such as in a distributed environment, applications should not attempt to provide strong transactional consistency. Instead, the application should achieve eventual consistency. In this model, a typical business operation consists of a series of autonomous steps. Although the overall view of these steps in the system State may be inconsistent, the system should be consistent when the operation has completed and all the steps have been performed.

Note:

The Data consistency Primer provides more information on why distributed transactions does not scale well, and the Princi Ples that underpin the eventual consistency model.

A significant challenge in the eventual consistency model is what to handle a step it has failed irrecoverably. In this case it is necessary to undo all of the work completed by the previous steps in the operation. However, the data cannot simply is rolled back because other concurrent instances of the application may has since change D it. Even in cases where the data have not been changed by a concurrent instance, undoing a step might not simply be a matter of Restoring the original state. It may is necessary to apply various business-specific rules (see the travel website described in the Example section).

A major challenge in the final consistency model is how to handle a failed step. In this case, it may be necessary to undo all the work done in the previous step. However, the data cannot be rolled back simply because other concurrent instances of the application may have changed it. Even if the concurrency of the data is not changed, undoing a step may not just restore the original state. It may be necessary to apply specific rules to various businesses (see example).

If An operation this implements eventual consistency spans several heterogeneous data stores, undoing the steps in such an Operation'll require visiting each data store in turn. The work performed in every data store must is undone reliably to prevent the system from remaining inconsistent.

If the final consistency is achieved across multiple heterogeneous data store operations, operations such as undo steps require access to each data store in turn. The work performed in each data store must be revoked to prevent system inconsistencies.

Not all data affected is operation that implements eventual consistency might is held in a database. In a service oriented Architecture (SOA) environment an operation could invoke an action in a service, and cause a change in The state is held by that service. To undo the operation, this state change must also is undone. This could involve invoking the service again and performing another action that reverses the effects of the first.

Not all of the data will affect the eventual consistency, possibly in a database. Operations in a service-oriented architecture (SOA) environment may cause changes in service state as a result of service invocation actions. Undo the action, and the state change must also be undone. This may involve invoking the service again and performing another reversal of the effect of the action. Solution Solutions

Implement a compensating transaction. The steps in a compensating transaction must undo the effects of the steps in the original operation. A compensating transaction might not being able to simply replace the "current" with the state the system is in the S Tart of the operation because this approach could overwrite changes made by other concurrent instances of an application. Rather, it must is an intelligent process, the takes into account, of any work done by concurrent instances. This process would usually is application-specific, driven by the nature of the work performed by the original operation.

Implements a compensating transaction. The steps in the compensating transaction must undo the effect of the original operation step. A compensating transaction may not be able to simply replace the state of the current running state, because this method can overwrite other concurrent instances of the application to make changes. Instead, it must be an intelligent process that takes into account any work done by concurrent instances. This process is typically application-specific and is driven by the nature of the work performed by the original operation.

A common approach to implementing an eventually consistent operation the requires compensation is to use a workflow. As the original operation proceeds, the system records information about each step and how the work performed by that step can be undone. If The operation fails at any point, the workflow rewinds back through the steps it had completed and performs the work th At reverses each step. Note that a compensating transaction might not having to undo the work in the exact mirror-opposite order of the original OP Eration, and it may is possible to perform some of the undo steps in parallel.

A common way to achieve a final consistent operation is to use a workflow to compensate for the operation. As the original operation, the system records information about each step and how to complete the work performed by that step. If the operation fails at any time, the workflow returns to each step that the step has completed and that the work is performed. Note that compensating transactions may not need to be undone in the reverse order of the mirrors of the original operation, and it may be possible to perform some parallel undo steps.

Note:

This approach was similar to the sagas strategy. A Description of this strategy are available online in Clemens vasters ' blog.

A compensating transaction is itself an eventually consistent operation and it could also fail. The system should is able to resume the compensating transaction at the point of failure and continue. It may is necessary to repeat a step that have failed, so the steps in a compensating transaction should be defined as idem Potent commands. For more information about idempotency, see idempotency Patterns on Jonathan Oliver's blog.

The compensatory transaction itself is a final, consistent operation and may fail. The system should be able to recover the compensating operation at the point of failure and continue. You may need to repeat the failed step, so the steps in compensating the transaction should be defined as idempotent commands. For more information on idempotent, see Idempotency Patterns on Jonathan Oliver's blog.

In the some cases it may is possible to recover from a step which has failed except through manual intervention. In these situations the system should raise a alert and provide as much information as possible about the reason for the Failure.

In some cases, it may not be possible to recover from a failed step, except through manual intervention. In this case, the system should provide an alert and provide as much information as possible for the cause of the failure. Issues and considerations issues and considerations

Consider the following points when deciding how to implement this pattern:

When deciding how to implement this pattern, consider the following points:

• It might not being easy-determine when a step in an operation that implements eventual consistency had failed. A step might not-fail immediately, but instead it could block. It is necessary to implement some form of time-out mechanism.
• This may not be easy to decide, and the operation fails at a certain step in a final consistency operation. A step may not fail immediately, but it is blocked instead. It may need to implement some form of timeout mechanism.
• Compensation logic is not easily generalized. A compensating transaction is application-specific; It relies on the application have sufficient information to being able to undo the effects of each step in a failed Operati On.
• Compensation logic is not easy to popularize. A compensating transaction is application-specific, and it relies on the application to have enough information to undo the impact of each step in a failed operation.
• You should define the steps in a compensating transaction as idempotent commands. This enables the steps to be repeated if the compensating transaction itself fails.
• You should define an order that compensates for the power of the transaction. This makes it possible to repeat the steps if the compensation itself fails.
• The infrastructure that handles the steps in the original operation, and the compensating transaction, must is resilient. It must not lose the information required to compensate for a failing step, and it must is able to reliably monitor the PR Ogress of the compensation logic.
• The basis for handling the steps and compensating transactions in the original operation must be resilient. It cannot lose the information needed to compensate for a failed step, and it must be able to reliably monitor the process of the compensation logic.
• A compensating transaction does not necessarily return the data in the system to the state it is in the The O Riginal operation. Instead, it compensates for the work performed by the steps that completed successfully before the operation failed.
• Compensating transactions do not have to be returned to the data in the system at the beginning of the original operation. Instead, it compensates for the work accomplished by the steps that were completed before the operation failed.
• The order of the steps in the compensating transaction does not necessarily has to be the mirror opposite of the steps in The original operation. For example, one data store is more sensitive to inconsistencies than another, and so the steps in the compensating TR Ansaction that undo the changes to this store should occur first.
• The order of steps in the compensating transaction is not necessarily mirrored in the original operation step. For example, one data store might be more sensitive than the other, so the steps to undo changes to that store should occur first in a compensating transaction.
• Placing a short-term timeout-based lock on all resource that's required to complete an operation, and obtaining these re Sources in advance, can help increase the likelihood, the overall activity would succeed. The work should is performed only after all the resources has been acquired. All actions must is finalized before the locks expire.
• Placing a short time-out lock on each resource to complete an operation and get these resources in advance can help increase the likelihood of overall activity. All the resources were acquired before the work was carried out. All actions must be completed before the lock expires.
• Consider using retry logic that's more forgiving than usual to minimize failures that trigger a compensating transaction. If a step in an operation that implements eventual consistency fails, try handling the failure as a transient exception a nd repeat the step. Only abort the operation and initiate a compensating transaction if a step fails repeatedly or irrecoverably.
• Consider using retry logic, which is usually easier to reduce failures and trigger a compensating transaction. If the steps to achieve eventual consistency in an operation fail, try to handle the failure as a temporary exception, and then repeat the steps. Only abort the operation if one step fails or starts the compensating transaction repeatedly.

Note:

Many of the challenges and issues of implementing a compensating transaction is the same as those concerned with implemen Ting eventual consistency. See the sections considerations for implementing eventual consistency on the Data consistency Primer for more information.

When to uses this pattern

The use of this pattern is operations that must is undone if they fail. If possible, design solutions to avoid the complexity of requiring compensating transactions (for more information, see th E Data consistency Primer).

Use this mode only for operations that must be if they cannot be revoked. If possible, design the solution to avoid complex requirements compensation transactions (more information, see Data consistency primers). Example Example

A travel website enables customers to book itineraries. A single itinerary may comprise a series of flights and hotels. A customer traveling from Seattle to London and then in to Paris could perform the following steps when creating an Itiner ary

A travel site that enables customers to book trips. A single itinerary can include a range of flights and hotels. A customer from Seattle to London, then to Paris, when creating a trip, you can perform the following steps:

1. Book a seat the flight F1 from Seattle to London.
2. Book a seat the flight F2 from London to Paris.
3. Book a seat the flight F3 from Paris to Seattle.
4. Reserve A-hotel H1 in London.
5. Reserve A-hotel H2 in Paris.

Book a flight from Seattle to London F1.
Book a flight from London to Paris F2.
Book a flight from Paris to Seattle F3.
Reserve in a London hotel H1.
Book a room at the Paris hotel.

These steps constitute an eventually consistent operation, although each step was essentially a separate atomic action in I TS own right. Therefore, as well as performing these steps, the system must also record the counter operations necessary to undo each St EP in case the customer decides to cancel the itinerary. The steps necessary to perform the counter operations can then run as a compensating transaction if necessary.

These steps form the final consistency operation, although each step is essentially a separate atomic action in its own right. Therefore, as well as when you perform these steps, the system must also record the actions necessary to undo the counter in the case that the customer decides to cancel the trip in each step. You must then perform a counter action step to run a compensatory transaction when needed.

Notice the steps in the compensating transaction might isn't be the exact opposite of the original steps, and the logic In each step of the compensating transaction must take to account any business-specific rules. For example, ' unbooking ' a seat on a flight might not entitle ' customer to a ' complete refund of any money paid.

Note that the steps in compensating the transaction may not be the exact opposite of the original step, and any specific business rule logic must be taken into account in each step of the compensating transaction. For example, a "booking" seat on a flight may not be eligible for a full refund of any monies paid by the customer.

Figure 1-generating a compensating transaction to undo a long-running transaction to book a travel itinerary

Figure 1-Generating a compensating transaction undoing a long-running transaction booking travel itinerary

Note:

It May is possible for the steps in the compensating transaction to being performed in parallel, depending Signed the compensating logic for each step.

It is possible that the steps in compensating the transaction parallel depend on how you designed the compensation logic to be executed in each step.

In many business solutions, failure of a single step does do necessitate rolling the system back by using a compen sating transaction. For example, If-after has booked flights F1, F2, and F3 in the travel website Scenario-the customer are unable to Reserv E A-class at Hotel H1, it's preferable to offer the customer a hostel at a different hotel in the same city rather than Canc Elling the flights. The customer may still elect-to-cancel (in which case, the compensating transaction runs and undoes the bookings made on FL Ights F1, F2, and F3), but this decision should is made by the customer rather than by the system.

In many business solutions, a single step failure is not always necessary to use a compensating transaction for rolling system recovery. For example, with a scheduled flight F1,F2 and F3 in a travel site scenario when a customer cannot book a hotel H1 if-after that, it is best to provide the customer with a room in the same city at a different hotel instead of canceling the flight. Customers can still choose to cancel (in this case, the compensation transaction runs and revoke the bookings made on the flight F1,F2 and F3), but the decision should be made by the user, not by the system. Related Patterns and Guidance related patterns and guidance

The following patterns and guidance may also is relevant when implementing this pattern:

• Data consistency Primer. The compensating Transaction pattern is frequently used to undo operations that implement the eventual consistency model. This primer provides more information on the benefits and tradeoffs of eventual consistency.
• Scheduler-agent-supervisor Pattern. This pattern describes what to implement resilient systems, perform business operations that utilize distributed Servic ES and resources. In some circumstances, it could be necessary to undo the work performed by an operation by using a compensating transaction.
• Retry Pattern. Compensating transactions can is expensive to perform, and it may is possible to minimize their use by implementing an EFF Ective policy of retrying failing operations by following the Retry pattern.

More information For more information

• The article sagas on Clemens vasters ' blog.
• The article idempotency Patterns on Jonathan Oliver's blog.

Compensating Transaction pattern (transaction fixup mode)