topic Re: SQL Deadlock in Alfresco Archive

SQL Deadlock

pault — Wed, 29 Dec 2010 13:19:15 GMT

I am hitting a deadlock at a point where 2 threads start processes in quick succession. 9 times out of 10 it is fine, but on occasions I get the deadlock below.It looks like one thread is starting a process while another is setting variables? I guess I am doing something wrong, any pointers on what

Re: SQL Deadlock

pault — Wed, 05 Jan 2011 08:28:53 GMT

I read in a reply elsewhere :

Using the activiti API from within activiti-context (JavaDelegate or TaskListeners) is a bad idea, this can mess up command-context and transactions in activiti. When you start a process-instance this way, the thread that drives the execution (which is used to invoke your code) will be used to run the spawned process instance (until it ends or reaches a wait-state).

Could this is my problem too ? I am starting a process from an object instantiated by a Java Service task. The requirement is to start an exception process in response to some condition, but in a different PVM, so I dont think it can be modelled in the process.

So I think I need to put something like a message queue in between, or somehow force a it onto a new thread in the service task.

In the quote above it says using the API within a JavaDelegate is a bad idea - am I correct in saying that is just those API calls that result in data being committed ?

Re: SQL Deadlock

jbarrez — Wed, 05 Jan 2011 14:36:51 GMT

It looks like you are indeed trying to lock the same entity in different threads,
hence the reason why it sometimes works and sometimes not.

Could this is my problem too ? I am starting a process from an object instantiated by a Java Service task. The requirement is to start an exception process in response to some condition, but in a different PVM, so I dont think it can be modelled in the process.

Do you mean starting a process on another Activiti instance?

So I think I need to put something like a message queue in between, or somehow force a it onto a new thread in the service task.

A message queue would be a solution; albeit a heavy one.
It should be possible just to start a new process from a service task.

In the quote above it says using the API within a JavaDelegate is a bad idea - am I correct in saying that is just those API calls that result in data being committed ?

Well, the reason why it is a bad practice, is because the API call will also create a new transaction; new commandcontext, etc.
For a workaround: check how the startProcessInstanceXX actually is run behind the scenes, and call that method.

Re: SQL Deadlock

pault — Wed, 05 Jan 2011 15:18:03 GMT

Thanks for the info. I think it gives me enough to work on and understand what is happening. Though having turned off the history service in the process engine that had the issue (it doesn't need it in any case), I haven't seen the problem since.

Do you mean starting a process on another Activiti instance

In the example I am working on I have an application that is implemented as Activiti processes, and which interacts with other Activiti processes (outside my application) that may be running in different process engines. So yes it may be in another process engine instance.

Re: SQL Deadlock

jcosano — Wed, 05 Jan 2011 15:51:48 GMT

Well, the reason why it is a bad practice, is because the API call will also create a new transaction; new commandcontext, etc.

I don't understand this…

If I call to API inside a JavaDelegate class, for sample create a processinstance… then… I'm using the same transaction … is it true??

I think that maybe is useful a small documentation about activiti transactions.

Re: SQL Deadlock

jbarrez — Thu, 06 Jan 2011 09:10:17 GMT

Depending on your configuration, it will run in the same transaction. If your are using the default standalone config, all is fine transaction-wise.

However, there are a few things going on when you call the API, which might screw it. We advise not to do it, since we havent tested it enought yet to be satisfied.