topic Re: CommandContext reuse with REQUIRES_NEW propagation inside service task in Alfresco Archive

CommandContext reuse with REQUIRES_NEW propagation inside service task

stuartchalmers — Wed, 31 Jul 2013 21:54:42 GMT

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" busine

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

stuartchalmers — Thu, 01 Aug 2013 08:14:37 GMT

I realised this morning I may be able to work around this by disabling CommandContext reuse in the ProcessEngineConfiguration.
It would be good to hear if anyone has any thoughts on this, and whether it can be considered a bug.
I'm going to try and reproduce this with a simpler test case in the meantime so that I can verify if disabling the reuse works in the way I expect.

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

jbarrez — Thu, 01 Aug 2013 14:01:03 GMT

The CommandContextInterceptor https://github.com/Activiti/Activiti/blob/master/modules/activiti-engine/src/main/java/org/activiti/engine/impl/interceptor/CommandContextInterceptor.java does have a property which you can use to disable this behavior.

Don't let the comment there fool you. The ProcessEngineConfiguration does set it to true. So to fix your problem: subclass the relevant ProcessEngineConfiguration and pass false to that property.

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

stuartchalmers — Thu, 01 Aug 2013 15:48:14 GMT

Thanks Joram,

We've made this change to workaround the issue and are in the process of testing it.

It would be nice if the CommandContextInterceptor could be more intelligent in some way around this as the behaviour had us pretty confused for a while so might impact others, although I guess our use case is rare.

If I get a chance I will look at the source again to see if I can think of any cleaner solution, as we could have other scenarios where the reuse does make sense in the same engine.

Regards
Stuart

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

frederikherema1 — Mon, 05 Aug 2013 07:48:21 GMT

Great, keep us posted on your progress…

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

marcus1 — Tue, 06 Aug 2013 20:40:23 GMT

This may be related to what I'm working on for ACT-1758.

See GitHub and specifically this commit (WIP).

The idea is that the CommandConfig allows fine-grained control over de CommandInterceptors per command execution (or use the default config).

At the moment the transaction propagation and context reuse can be configured. I think the RetryInterceptor settings are another good candidate for inclusion. This way there is no more need for having multiple interceptor chains per propagation kind. Being able to set whether context reuse is possible should be useful for the issue described in this thread.

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

jbarrez — Thu, 08 Aug 2013 08:27:09 GMT

That looks like an interesting improvement, what's the advantage of splitting the config up?

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

marcus1 — Thu, 08 Aug 2013 13:44:17 GMT

For ACT-1758 the schema commands need to run outside of a transaction. There is already the commandExecutorTxRequired and commandExecutorTxRequiresNew, so we could just add another one: commandExecutorTxNotSupported, and use that one for all the schema commands. However, this approach is not very scalable: it is conceivable that other commands need different interceptor combinations and configurations. For example, maybe we want to use the RetryInterceptor only (or except) for certain commands. So do we then add a retryingCommandExecutorTxRequired and a retryingCommandExecutorTxRequiresNew? This would very quickly lead to a unmanagement number or executors.

By decoupling the interceptor configuration from the interceptor stack this problem is avoided. Exactly one executor is sufficient. When passing a command to the executor, the exact configuration can be specified if desired. This allows for very fine grained configuration.

Ofcourse if one does not pass a CommandConfig the default one is used. Therefore most calls to execute can stay the same.

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

jbarrez — Wed, 14 Aug 2013 09:36:03 GMT

Okay - sounds good. We'll check the pull request!

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

marcus1 — Mon, 19 Aug 2013 07:55:20 GMT

Great! Let me know if you have any questions and such.

Re: CommandContext reuse with REQUIRES_NEW propagation inside service task

stuartchalmers — Thu, 10 Oct 2013 20:49:32 GMT

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