AnsweredAssumed Answered

CommandContext reuse with REQUIRES_NEW propagation inside service task

Question asked by stuartchalmers on Jul 31, 2013
Latest reply on Oct 10, 2013 by stuartchalmers
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

Outcomes