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.
Hi,
I did the same but used some custom JDBC code. Do you know of any extra implication that must be taken into consideration? Thanks.
Hi Alessandro,
Sorry for the late reply, not sure how I missed your comment.
The problem you run into when not using the WebSphere Adapter to do your JDBC calls is that you need to manually map between the DataObject representation of your business data and java objects. If your objects are simple, it’s not an issue. If they’re complicated, you could be setting yourself up to write a lot of very boring mapping code.
I wouldn’t say theres more issues than that. JNDI DataSources are used everywhere in WAS, I don’t see an potential “unsupported” issue in using them should anything go wrong.
hello dan,
i m calling create task of human task manager from a long running process using Invoke (Actual Human Task lookup is inside my Java code. I have to roll back the create task if there is any exception occurs after the create task step in my process.
I did the settings as u mentioned and make the activities in my process as “Participates” in the BPEL. But it is not rolling back the create task. Any idea? Is there any way to achieve this without writing compensation handler?
Please advise.
Thanks!
Jay
Hi Jay,
I haven’t used the Human Tasks API inside of a BPEL before, but it wouldn’t surprise me that the invocation isn’t a part of your global transaction. I guess you’ll need to catch the exception and then call the HT API to delete the instance that was created in error.
hello Dan,
Good explaination on the transactionality. I want some clear explaination in detail with all the other qualifiers where to use and when to use, like above instance..
Dan, we have multiple module interacting with the same database using jdbc import. And we ran into concurrency issues. Can you put some light on how to resolve this concurrency problem in database interactions pls.
Thank you.