cancel
Showing results for 
Search instead for 
Did you mean: 

CommandContext reuse with REQUIRES_NEW propagation inside service task

stuartchalmers
Champ in-the-making
Champ in-the-making
Hi,

We have an interesting problem which seems to be related to the introduction of command context reuse in newer versions of Activiti.
I understand the reason this was done, and have read the discussions/blog posts and they make complete sense.

To give some context, we have an existing "retry" business process which is used in some scenarios.
It basically contains a timer event and a service task in a loop (with some other bits and pieces in there).
The service task/Java delegate itself delegates to some other injected event class, and we want this to happen in a new transaction so the  implementation is marked as @Transactional (propagation=REQUIRES_NEW).

This used to mean that we got a new transaction inside the delegate (the transaction can include other DB work and not just Activiti), and on exception this would be rolled back, meanwhile the retry process operating in a different transaction was not and could handle the exception and loop back to the timer, successfully committing its state.
The delegate often itself starts a new Activiti process using RuntimeService. I know this used to be a bad idea in general but as far as I remember for this use case it was fine previously as this process had its own CommandContext / transaction and could be rolled back and the retry loop can continue.

I may have missed something here but as far as I can see, the issue we have now is that even though we are still creating a new transaction inside the delegate, and non-Activiti work is still rolled back, the Activiti work which is done still joins the existing transaction and is not rolled back. This is because the CommandContext is reused, and the DbSqlSession is not flushed until the reused CommandContext is closed when the timer job command completes.

Should/could the CommandInterceptor not check if the current transaction context is the same as it was in the previous command before attempting to reuse it? If not it should still create a new context so that the db changes can be flushed and committed in the new transaction?

Thanks in advance for your thoughts and / or suggestions!

Best Regards
Stuart
10 REPLIES 10

stuartchalmers
Champ in-the-making
Champ in-the-making
Sorry for the delayed response on this. I work for a fast moving business and got pulled into something else!
Marcus, thanks so much for your contribution and reply to my original post. I've just come across a scenario where I do indeed want the context reuse, after having disabled it in the config.
I've reviewed your change and it looks like just what I need!
Roll on 5.14  so I can get my hands on this Smiley Happy