Transaction compensation and business activity support
A business activity is a collection of tasks that are linked together so that they have an agreed outcome. Unlike atomic transactions, activities such as sending an email can be difficult or impossible to roll back atomically, and therefore require a compensation process in the event of an error. The WebSphere Application Server business activity support provides this compensation ability through business activity scopes.
When to use business activity support
Use the business activity support when we have an application that requires compensation. An application requires compensation if its operations cannot be atomically rolled back. Typically, this scenario is because of one of the following reasons:
- The application uses multiple non-extended-architecture (XA) resources.
- The application uses more than one atomic transaction, for example, enterprise beans that have Requires new as the setting for the Transaction field in the container transaction deployment descriptor.
- The application does not run under a global transaction.
The following diagram shows a simple web service application that uses the business activity support. The Retailer, Warehouse and anufacturing services are running in non-WASenvironments. The Retailer service calls the Supplier service, running on WAS, which delegates tasks to the Warehouse and Manufacturing services. The implementation of the Supplier service contains a stateless session bean, which calls other stateless session beans associated with the Warehouse and Manufacturing services, and that undertake work that can be compensated. These other session beans each have a compensation handler; a piece of logic associated with an application component at run time, and performs compensation activity such as resending an email.
Application design
Business activity contexts are propagated with application messages, and can therefore be distributed between application components that are not co-located in the same server. Unlike atomic transaction contexts, business activity contexts are propagated on both synchronous (blocking) call-response messages and asynchronous one-way messages. An application component that runs under a business activity scope is responsible for ensuring any asynchronous work it initiates is complete before the component's own processing is complete. An application that initiates asynchronous work using a fire-and-forget message pattern must not use business activity scopes, because such applications have no means of detecting whether this asynchronous processing has completed.
Only enterprise beans that have container-managed transactions can use the business activity functions. Enterprise beans that exploit business activity scopes can offer web service interfaces, but can also offer standard enterprise bean local or remote Java interfaces. Business activity context is propagated in web service messages using a standard, interoperable Web Services Business Activity (WS-BA) CoordinationContext element. WAS can also propagate business activity context on RMI calls to enterprise beans when Web services are not being used, but this form of the context is not interoperable with non-WAS environments. We might want to use this homogeneous scenario if you require compensation for an application that is internal to the business. To use business activity compensation in a heterogeneous environment, expose the application components as web services.
Business activity contexts can be propagated across firewalls and outside the WAS domain. The topology used to achieve this propagation can affect the high availability and affinity behavior of the business activity transaction.
Application development and deployment
WAS provides a programming model for creating business activity scopes, and for associating compensation handlers with those business activity scopes. WAS also provides an application programming interface to specify compensation data, and check or alter the status of a business activity. To use the business activity support we must set certain application deployment descriptors appropriately, provide a compensation handler class if required, and enable business activity support on any servers that run the application.Applications can exploit the business activity support only if we deploy them to a WAS at v6.1 or later. Applications cannot use the business activity support if we deploy them to a cluster that includes WASv6.0.x servers.
Business activity scopes
The scope of a business activity is that of a main WAS unit of work: a global transaction, an activity session, or local transaction containment (LTC). A business activity scope is not a new unit of work (UOW); it is an attribute of an existing main UOW. Therefore, a one-to-one relationship exists between a business activity scope and a UOW.
In a WS-BA deployment, the UOW must be container-managed:
- The UOW can be a container-managed transaction (CMT) enterprise bean that creates a global transaction.
- The UOW can be a local transaction containment (LTC) where the container is responsible for initiating and ending resource manager local transactions (RMLTs). That is, in the transactional deployment descriptor attributes, the Local Transaction attribute Resolver must be set to ContainerAtBoundary. To use WS-BA, we must not set the Resolver attribute to Application.
Any main UOW can have a business activity scope associated with it. If a component running under a UOW associated with a business activity scope calls another component, that request propagates the business activity scope; any work done by the new component is associated with the same business activity scope as the calling component. The called component can create a new UOW, for example if an enterprise bean has a Transaction setting of Requires new, or runs under the same UOW as the calling component. If a new UOW is started then a new business activity scope is created and associated with the new UOW. The newly created business activity scope is a child of the business activity scope associated with the calling UOW. In the following diagram, EJB1a running under UOW1 calls two components: EJB1b that also runs under UOW1, and EJB2 that creates a new UOW, UOW2. The enterprise bean EJB1b, calls another enterprise bean, EJB3, which creates another new UOW, UOW3. Because each new UOW is created by a calling component whose UOW already has an association with business activity scope BAScope1, the newly created UOWs are associated with new inner business activity scopes, BAScope2 and BAScope3.
Inner business activity scopes must complete before the outer business activity scope completes. Inner business activity scopes, for example BAScope2, have an association with the outer business activity scope, in this case BAScope1. Each business activity scope is directed to close if its associated UOW completes successfully, or to compensate if its associated UOW fails. If BAScope2 completes successfully, any active compensation handlers that are owned by BAScope2 are moved to BAScope1, and are directed in the same way as the completion direction of BAScope1: either compensate or close. If BAScope2 fails, the active compensation handlers are compensated automatically, and nothing is moved to the outer BAScope1. When an inner business activity scope fails, as a result of its associated UOW failing, an application server exception is thrown to the to calling application component, running in the outer UOW.
For example, if the inner UOW fails it might throw a TransactionRolledBackException exception. If the calling application can handle the exception, for example by trying the called component again or by calling another component, then the calling UOW, and its associated business activity scope, can complete successfully even though the inner business activity scope failed. If the application design requires the calling UOW to fail, and for its associated business activity scope to be compensated, then the calling application component must cause its UOW to fail, for example by allowing any system exception from the UOW that failed to be handled by its container.
When the outer business activity scope completes, its success or failure determines the completion direction (close or compensate) of any active compensation handlers that are owned by the outer business activity scope, including those promoted by the successful completion of inner business activity scopes. If the outer business activity scope completes successfully, it drives all active compensation handlers to close. If the outer business activity scope fails, it drives all active compensation handlers to compensate.
This compensation behavior is summarized in the following table.
| Inner business activity scope | Outer business activity scope | Compensation behavior |
|---|---|---|
| Succeeds | Succeeds | Any compensation handlers that are owned by the inner business activity scope wait for the outer UOW to complete. When the outer UOW succeeds, the outer business activity scope drives all compensation handlers to close. |
| Fails | Succeeds | Any active compensation handlers that are owned by the inner business activity scope are compensated. An exception is thrown to the outer UOW; if this exception is caught, when the outer UOW succeeds, the outer business activity scope drives all remaining active compensation handlers to close. |
| Fails | Fails | Any active compensation handlers that are owned by the inner business activity scope are compensated. An exception is thrown to the outer UOW; if this exception is not caught, the outer business activity scope fails. When the outer business activity scope fails, either because of the unhandled exception or for some other reason, all remaining active compensation handlers are compensated. |
| Succeeds | Fails | Any compensation handlers that are owned by the inner business activity scope wait for the outer UOW to complete. When the outer UOW fails, the outer business activity scope drives all compensation handlers to compensate. |
When a UOW with an associated business activity scope completes, the business activity scope always completes in the same direction as the UOW that it is associated with. The only way that we can influence the direction of the business activity scope is to influence the UOW that it is associated with, which we can do using the setCompensateOnly method of the business activity API.
A compensation handler registered within a transactional UOW might initially be inactive, depending on the method invoked from the business activity API. Inactive handlers in this situation become active when the UOW in which that handler is declared completes successfully. A compensation handler registered outside a transactional UOW always becomes active immediately. See topic about the business activity API.
Each business activity scope in the diagram represents a business activity. For example, the outer business activity running under BAScope1 can be a holiday booking scenario, with BAScope2 being a flight booking activity and BAScope3 a hotel booking. If either the flight or hotel bookings fail, the overall holiday booking by default also fails. Alternatively if, for example, the flight booking fails, we might want the application to try booking a flight using another component that represents a different airline. If the overall holiday booking fails, the application can use compensation handlers to cancel any flights or hotels that are already successfully booked.
Use of business activity scopes by application components
Application components do not use business activity scopes by default. We use the WAS assembly tools to specify the use of a business activity scope and to identify any compensation handler class for the component:
- Default configuration
- If a business activity context is present on a request received by a component with no business activity scope configuration, the context is stored by the container but never used during the method scope of the target component. A new business activity scope is not created. If the target component invokes another component, the stored business activity context is propagated and can be used by other compensating components.
- Run enterprise bean methods under a business activity scope
- Any business activity context present on the incoming request is received by the container and made available to the target component. If a new UOW is created for the target method, for example because the enterprise bean method has a Transaction setting of Requires new, the received business activity scope becomes an outer business activity scope to a newly created business activity. If the UOW is propagated from the calling component and used by the method, then the received business activity scope is used by the method. If a business activity scope does not exist on the invocation, a new business activity scope is created and used by the method.
Related: