<emphasisrole="bold">Note:</emphasis> it is important not to confuse the bpmn transaction subprocess with
technical (ACID) transactions. The bpmn transaction subprocess is not a way to scope technical transactions.
In order to understand transaction management in activiti, read the section on
<linklinkend="bpmnConcurrencyAndTransactions">concurrency and transactions</link>.
A bpmn transaction is different from a technical transaction in the following ways:
<itemizedlist>
<listitem>
<para>
While an ACID transaction is typically short lived, a bpmn transaction may take hours, days or even months
to complete. (Consider the case where one of the activities grouped by a transaction is a usertask,
typically people have longer response times than applications. Or, in another situation, a bpmn transaction might wait
for some business event to occur, like the fact that a particular order has been fulfilled.) Such operations
usually take considerably longer to complete than updating a record in a database, or storing a message using
a transactional queue.
</para>
</listitem>
<listitem>
<para>
Because it is impossible to scope a technical transaction to the duration of a business activity, a bpmn transaction typically
spans multiple ACID transactions.
</para>
</listitem>
<listitem>
<para>
Since a bpmn transaction spans multiple ACID transactions, we loose ACID properties. For example, consider the example given above.
Let's assume the "book hotel" and the "charge credit card" operations are performed in separate ACID transactions. Let's also assume that
the "book hotel" activity is successful. Now we have an intermediary inconsistent state, because we have performed an hotel booking but have
not yet charged the credit card. Now, in an ACID transaction, we would also perform different operations sequentially and thus also have an
intermediary inconsistent state. What is different here, is that the inconsistent state is visible outside of the scope of the transaction.
For example, if the reservations are made using an external booking service, other parties using the same booking service might already see that
the hotel is booked. This means, that when implementing business transactions, we completely loose the isolation property (Granted: we usually also
relax isolation when working with ACID transactions to allow for higher levels of concurrency, but there we have fine grained control and intermediary
inconsistencies are only present for very short periods of times).
</para>
</listitem>
<listitem>
<para>
A bpmn business transaction can also not be rolled back in the traditional sense. Since it spans multiple ACID transactions, some of these ACID
transactions might already be committed at the time the bpmn transaction is cancelled. At this point, they cannot be rolled back anymore.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Since bpmn transactions are long-running in nature, the lack of isolation and a rollback mechanism need to be dealt with differently. In practice, there is usually
no better solution than to deal with these problems in a domain specific way:
<itemizedlist>
<listitem>
<para>
The rollback is performed using compensation. If a cancel event is thrown in the scope of a transaction, the effects of all activities that executed
successfully and have a compensation handler are compensated.
</para>
</listitem>
<listitem>
<para>
The lack of isolation is also often dealt with using domain specific solutions. For instance, in the example above, an hotel room might appear to be
booked to a second customer, before we have actually made sure that the first customer can pay for it. Since this might be undesirable from a business
perspective, a booking service might choose to allow for a certain amount of overbooking.
</para>
</listitem>
<listitem>
<para>
In addition, since the transaction can be aborted in case of a hazard, the booking service has to deal with the situation where a hotel room is booked
but payment is never attempted (since the transaction was aborted). In that case the booking service might choose a strategy where a hotel room is
reserved for a maximum period of time and if payment is not received until then, the booking is cancelled.
</para>
</listitem>
</itemizedlist>
To sum it up: while ACID transactions offer a generic solution to such problems (rollback, isolation levels and heuristic outcomes),
we need to find domain specific solutions to these problems when implementing business transactions.
