Suspend operation failed

[rainman]

Hi, all
I was to suspend an process instance during the execution of a asynchronous service task, but the engine report the following exception:

             ExecutionEntity was updated by another transaction concurrently.

I debugged the engine, and find that the SuspendProcessInstanceCmd and the ExecutionJobCmd have different command contexts each of which has a persistence object cache itself.

The SuspendProcessInstanceCmd intend to get the execution entity from its own command context, in case of failure, it create an new ExecutionEntity instance from the database and flush it to the database on the end of the command, while in the same time, there is already an ExecutionEntity in the command context of ExecutionJobCmd. So, when the ExecutionJobCmd flushes the ExecutionEntity, the database would not do the update because it's not consistent with the record in the Execution table.

So I think maybe we can add an shared persistence object cache to each command context stack, and put the ExecutionEntity and other persistence objects that may need to be access by other commands in the shared cache. And all the persistence objects are flushed only by the command context that create it.

Is this scalable?

[ronald_van_kuij]

Won't this already work if you have a transaction managed outside the engine? E.g. Using a jta transactionmanager? There will be no commit then in each command executed and thus no clashes?

[rainman]

Thanks for your reply

[rainman]

Won't this already work if you have a transaction managed outside the engine? E.g. Using a jta transactionmanager? There will be no commit then in each command executed and thus no clashes?

Sir, did you mean use "JtaProcessEngineConfiguration"?

[meyerd]

In your service task:

Context.getCommandContext()
   .execute(new SuspendProcessInstanceCmd(…));
this allows you to combine both commands into a single command context.

–

Wat Ronald suggests is that if you use a thread-aware transaction and connection propagation mechanism like JTA or Spring transactions, the "inner" command will not open a new DB connection but reuse the connection already obtained by the "outer" command, since it is bound to the thread.