Executing a business process without a transaction is beneficial in scenarios similar to the following:

• Assume you have a BPEL process in which a flowN activity spawns 2000 branches. Each branch invokes a remote synchronous web service that takes 500 ms to respond. Because the BPEL process service engine executes flowN branches individually in a single thread, processing all 2000 branches with each one invoking a synchronous web service takes close to 1000 seconds and the instance does not have access to the dehydration point during this processing. The transaction can extend for 1000 seconds and can time out (the default transaction timeout setting is 300 seconds). Everything can be performed directly in memory without the need for a transaction.

• The duration of a transaction gets tied up with the life cycle of business process execution. For example, assume an asynchronous BPEL process includes a receive activity followed by an assign activity in which a complex XSL transformation performed on a large document takes 30 seconds. This is followed by a callback to the client. If executed in a transaction, the BPEL process service engine starts the transaction at the receive activity and holds a lock inside the database on the instance while the instance is executing.

  As an alternative, all activities can be performed in memory and discarded if an error occurs. A transaction is not required because a database update does not occur during instance execution. A transaction is only required once instance execution reaches the dehydration point, where the BPEL process service engine updates the instance state, and so on.

• Assume a BPEL process invokes another service or partner link that is synchronous and participates in a BPEL process service engine's JTA transaction (for example, if a BPEL process invokes the TaskServiceBean, which has TransactionAttribute=REQUIRED, and there is a TaskServiceBean time out and the transaction is roll backed). Even the BPEL process service engine's JTA transaction gets rolled back and the BPEL process is unable to handle the error from the TaskServiceBean.

• If a business process invokes a synchronous service and that service is performing complex work that takes a considerable amount of time, the BPEL process service engine transaction can time out. Even though the synchronous service is performing correctly, the BPEL process service engine rolls back once the business process gets a response from a remote service.