Why spring nested transaction doesn't work

Flowable Engine
1

I have a service task which throws an exception .
In the catch block, another spring bean method is called to update the process variables
using delegateExecution.setVariables("","");

The process variable set by spring bean method is not stored as the whole transaction is rolled back. (Which is expected)

In the spring bean method, I added @Transactional(propagation = Propagation.REQUIRES_NEW)
thinking that it will create a new transaction and update the process variable.
But this change is also getting rolled back it seems.

I use a JDBC connection to a Microsoft SQL database.

2

Iā€™m not entirely certain the exact cause but the @Transactional attribute has a few potential pitfalls because of the way Spring uses proxies to handle transactions. You can look at this page: Transactions with Spring and JPA | Baeldung, especially section 5 to see if it is applicable to your use case. A potential work around, if you need it, is to create your own transactions programmatically and call the setVariables method within it.

1 Like
3

Hey @bijeshcnair,

What is explained by @jwashington is correct. What I would like to add on top of that is that you if you are creating new transactions while within an already existing transaction certain things might not work correctly. Flowable does some optimizations and only flushes to the database when its transaction is completed, which means that if you try to modify something which from a different transaction you might not see it.

Cheers,
Filip

4

Yes changing Flowable transaction scopes is not a good idea and is a intrusive approach. Probably some form of the saga pattern or perhaps utilizing Flowable compensation would be a much cleaner way to update workflow variables in the event the service task fails.

5

@jwashington I did implement considering the nested transaction pit fall.
Its an external methdo call.

@filiphr I understand. I think that is the reason the process variables are not getting updated in the nested transaction.