Transactionality in SCA – Part 2 – Refactoring Interfaces
July 31, 2008 1 Comment
More than once, customers have asked me:
‘I want to control the transactionality in my Mediation Module so that I can implement a service’s operation with three calls to a JDBC adapter – and I want them all to be tied together – either the whole operation succeeds or fails. How can I do that?’.
Well, as of WebSphere ESB 6.1, this is pretty easy. Just tie together an export of some sort, a mediation flow component, and a JDBC adapter in a Mediation Module, in a global transaction, using the techniques referenced in Part 1 of this series. Then use the new Service Invoke mediation primitive to do three sequential invocations of the JDBC adapter, and Bob’s your uncle.
The result will look something like this:
However, it sometimes gets a bit more complicated.
OK, that’s great. Now we need to implement an operation where three calls to the database need to be bound together into a transaction. However, one subsequent call should sit outside the transaction – if it fails, it shouldn’t affect the other three. How can I do that?
The trick lies in refactoring the interfaces involved. Take the mediation flow component, and conceptually split it into two, componentA and componentB. The export connects to componentA, which connects to componentB, which connects to the JDBC adapter. componentA should also be connected directly to the JDBC adapter. componentA should have the same interface as before. However, you should create a new interface for componentB, which has an operation for each transaction that needs to be bound together (the three calls to the database in our example above).
(the gotcha here is that in a mediation module, you can only have one mediation flow component, so componentB will have to be a Java component)
Here’s the important part: make sure the global transaction boundaries cover componentB and the database only. Do not include componentA or the export.
Now, have the ‘master’ operation in componentA call your new operation on componentB first. Then, have it call the other operation on the JDBC adapter directly (the one that shouldn’t be tied into the transaction).
Your transactional scenario is now set up as requested, and will behave to tie together the first three calls to the database (or whatever else you do in the operation implementation in componentB). It should look like this: