Consider the following module:

We have a Web Service Export connecting to a BPEL process which invokes the WebSphere Adapter for JDBC. The BPEL process has two invocations to insert two rows into the database. I have a business requirement that either both rows get inserted or no rows.

Now in the success case, when I invoke this module I will see that two rows are written to the database.

If I modify my BPEL to throw an exception in-between the two invokes then the BPEL process transaction will rollback. What do I now see in the database? The first row inserted into the database. It didn’t participate in the transaction spawned by the BPEL process/SCA container, therefore, it didn’t get rolled back. This has broken the business requirement.

Why did the BPEL transaction not propagate to the WebSphere Adapter for JDBC Import? The answer lies in the interface qualifier for the import.

You can find this by clicking on the interface icon on the import and looking in the properties view. Click the ‘Qualifiers’ tab and click the ‘Add’ button. There is a property called “JoinTransaction”. This property tells SCA that this component wants to “Join the transaction of the calling component”, ie transaction propagation. When “joinTransaction” is false, the SCA runtime interprets this as “This component should be run in it’s own local transaction”. By default when ‘joinTransaction’ is not specified, it behaves as FALSE.

If I change this property to TRUE and re-run my BPEL throwing a fault, I will see neither row inserted into the database.

The interactions between transactions is something that you need to pay attention to when developing your modules. Unfortunately, theres no graphical representation of transactions in the assembly diagram to make this job easier.

There is a hidden ‘gotcha’ in this scenario. Inside of a BPEL process, you have the ability to specify when a transaction should be committed. This is represented in the radio buttons “Commit Before, Commit After, Requires Own or Participates”. Be aware that these settings only apply to a LONG RUNNING PROCESS. Short running processes only exist in a single transaction from start to finish, so they either completely finish or completely rollback. There’s no ‘halfsies’ allowed. If you are using a short running process, then you have to ‘fiddle’ with the transactions as defined on the interface qualifiers.

Related Posts

• BPEL: Beware the use of nested loops in a short running process
• JDBC Adapter Export with events that comprise multiple rows
• Adding JMS or MQ/JMS Custom Header Attributes
• The VETO SOA Pattern
• WebSphere Default Messaging (SIBus) and WebService Error Handling

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.