4.2 Compensating Transactions
4.2.1 De nition of a Compensating Transaction
During a transactional method the implicit object is locked, disallowing others to see any state changes made by this transactional method. When a transactional method commits, the eect of its actions are viewed as state changes in the implicit object and the object is unlocked. When a transactional method aborts, state changes are ignored in the implicit object and it is unlocked. Other methods can now use and modify this unlocked object.
In Section 5.2 on nested transactions, we show how along with the implicit ob- ject other objects are locked when they are accessed by the current transactional method.
When using the more advanced transaction types, as long running transac- tions in the Section 5.1, we need a way to neutralize the eect of an already committed transaction. From time to time a committed transaction should be rolled back. One way to solve this is to lock the implicit object and keep the transactional method open, until we are sure no other method will request the roll back operation anymore. This is not a valuable option, since it will gradually lock more and more objects. This way, other clients frequently have to wait and sometimes deadlock is reached. Moreover, in our opinion it is not acceptable to keep the transactional methods open merely to provide transactional context information. Mind that in the database world transactions and compensating transactions are not associated with each other. We want to introduce language concepts to connect a compensating transaction to the speci c execution of an- other transaction.
Since a transactional method can only have one outcome, once it reached the commit outcome it cannot roll back anymore. In the database world compensat- ing transactions are used to neutralize the eect of an already committed trans- action. In the terms of this dissertation a compensating transactional method is introduced; this method neutralizes the eect of a speci c transactional method. To exemplify the use of compensation, consider the core of an application sup- porting banking operations. During some surrounding operation a transactional method withdraws a speci c amount from an account's balance. The transac- tional withdrawal method is nished, and the account is released for other clients to use. Suddenly, the business code of the surrounding operation decides to stop and all its eects should be neutralized. The developer of the surrounding oper- ation can not simply restore the balance of the account to the value before the withdrawal was made. Other clients might already have changed the balance of this same account. To neutralize the eect of the surrounding operation on the account, this developer needs to deposit exactly the speci c amount previously withdrawn from that account. This example shows that restoring the state to a previously recorded state, which is the most simple form to neutralize the eect
of a transactional method, does not guarantee the desired eect on the entire application.
Another example where compensation is needed is for a transactional method that drills a hole in a plate. After the method commits, the plate is irreversibly changed since it now contains a hole. If later on, the drilling action must be neutralized, the plate cannot simply revert to its original state but compensation is needed. The only way the hole can be neutralized in the plate, is by replacing the original plate with a new one. This example comes from the database world, where a new record can replace an existing record and use the same primary key. All other records, referencing this same key as a foreign key, are then related to the new record. In object-oriented programs however, it is not straightforward to replace an existing object. We are unable to replace an object in situ by a new object. Since this new object is located in a dierent memory location, other objects might still reference the original object. One way to solve this object replacement is to perform a sweep over the complete object population and substitute all references to the old object by references to the new object. However, current object-oriented environments do not allow a developer to sweep over this population.
A compensating method is thus a method which neutralizes the eect of a previously committed transactional method. In some circumstances compensa- tion stands for reverting the state changes made by the transactional method. In other circumstances, this stands for replacing the complete object. Section 4.2.2 elaborates on implementing the compensation behavior.
Compensating methods cannot exist by themselves, they are linked to an associated transactional method. But since the transactional method already nished its work, the body of the compensating method is clearly separated from the original body. Figure 4.3 shows the graphical notation for a compensating transaction.
4.2. COMPENSATING TRANSACTIONS 77 abort signal commit signal begin signal abort outcome commit outcome ~identifier abort signal commit signal begin signal abort outcome commit outcome identifier abort signal abort outcome commit signal begin signal commit outcome :~identifier( .. ) compensate abort outcome :identifier( .. ) commit signal begin signal abort signal commit outcome commit signal abort signal begin signal abort outcome commit outcome :System
type
instance
commit signal begin signal abort signal abort outcome commit outcome :~identifier( .. ) abort outcome :identifier( .. ) commit signal begin signal abort signal commit outcomeinstance
Figure 4.3: Compensational Transactions
The left hand side of Figure 4.3 shows a transaction type with its associ- ated compensating transaction type. These two transaction types are framed together, to endorse their relation as a compensational transaction. Moreover, their identi er is basically the same. A tilde pre x is used on the identi er of the compensating transaction type. This pre x is comparable to the naming convention of constructors and destructors in some object-oriented programming languages. We give the compensating transaction a matching name as the asso- ciated transaction, since it neutralizes the eect of this transaction.
The middle and right hand side of Figure 4.3 show the use of compensa- tional transaction types. The instance in the middle of the gure shows the transactional method executing. The associated compensating method, named ˜identifier, is shown in the bottom of the frame. This compensating method is not yet available, hence its signal ports are still disabled. The instance in the right hand side of the gure shows a transactional method which has n- ished its processing in a normal way. The context of the transactional method is not available anymore and the outcome reached the commit state. However, the eect of this transactional method could still be neutralized by the associ- ated compensating method. Therefore, the commit outcome of the transactional method is now displayed in a slanted and underlined font. The associated com- pensating method is enabled, and some external source has just signaled this
compensating method to neutralize the eect of the transactional method. In Chapter 5 on concepts for advanced transaction types, we show that the external source is a speci c transactional method managing the execution of the current transactional method, as well as other transactional methods. Once this man- aging transactional method reaches its commit state, the current transactional method reaches also its eective commit outcome. Moreover, the compensating transaction cannot be triggered anymore, its begin and commit ports are then disabled.
The fact that the abort port and the abort outcome are disabled in the com- pensating method, shows that we expect this compensating method never to fail. The compensating behavior is only called because of an external failure, and the eect of the transactional method should be neutralized. If the compensating method fails anyway, we reach an unrecoverable transaction fault leaving the entire application in an inconsistent state.