Transactionality - BPEL2.0 SE

It is important to understand with the BPEL2.0 SE how the "atomic" flag and persistence affects transactionality.

Take the default situation, "atomic=no" and "persistence=no"....

There are transaction boundaries wrapping the JMS BC / Receive and also the Invoke / JDBC BC. In order to understand what is happening with TXN-1 for example, it is important to visualize the NMR between the JMS BC and the Receive. The NMR will deliver the JMS message to the BPEL process and if successful will return an ACK back to the JMS BC at which point the transaction completes. The same happens between the Invoke and the JDBC BC.

This is typical in long-running Business Processes where the time taken to run the process far exceeds the transaction timeout. Any errors in such a process will have to be handled by the developer, possibly with compensation.

Now lets take an example of a short-running process, "atomic=yes" persistence="no"

Here we can see that the transaction boudary extends across the whole Business Process. In this situation the ACK is not sent back to the JMS BC until the JDBC BC has sent its ACK back to the BPEL Invoke activity. The major drawback of this approach is its blocking nature, hence it is only suitable for short-running processes.

One thing to note about this is - if all outbound partners are transactional (as in this example), then you get 'once-and-only-once' behavior, otherwise if at least one partner is non-transactional (e.g. File BC), then that partner could get the same message delivered more than once on the second attempt, hence 'at-least-once' behavior

Now lets take an example of a long-running process, atomic="no", persistence="yes"

Here we can see that the Business Process is persisted to a highly-available database, but the transaction boundaries remain the same as the default situation above (except, persistence to DB is added to the transaction boundaries)

It is worth understanding how persistence works in BPEL2.0; not every activity is persisted, only non-repeatable activities - e.g. Assign activities can be repeated so are not persistence points, Receive activities cannot be repeated so are persistence points, this makes persistence much less of an overhead than in BPEL1.0

As an example, if the process dies at 'Assign', recovery uses persisted version of the JMS message to repeat from 'Receive', hence guaranteeing 'once-and-only-once' delivery.