If you ask me, indexing will *not* prevent deadlocks...
So any suggestions on how to detect what is causing as the SQL error ("deadlock detected.") and line number in the Java code doesn't provide me details with what needs to be done to resolve the issue. Should I do a flush of the DB changes somewhere? Or is this really a jBPM issue, but ppl are sweeping it under the rug?
The strange thing about this error is that it doesn't occur all the time. I suppose it is either load related. Another possibility is the use of hibernate and/or the highly dynamic use-cases of the jBPM APIs. If I have any solution, I'll report back if anyone cares.
I also experiment deadlocks, but they occur each time (and only these times) I want to take a transition leading to a node that has already been visited. It happens on the commit when I want to close the JBPMSession. I'm using Jbpm 3.0.2, mysql-connector-java 3.0.11 and mysql 4.1.18 .
Here is a part of the logs:
17:54:24,984 WARN JDBCExceptionReporter : SQL Error: 1205, SQLState: 41000
17:54:24,984 ERROR JDBCExceptionReporter : Lock wait timeout exceeded; try restarting transaction
17:54:24,984 ERROR AbstractFlushingEventListener : Could not synchronize database state with session
org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
Any idea where it might be coming from ?
This is interesting... Can you please provide us with a unit test demonstrating this behaviour?
I found the reason of this behaviour. It is not a bug in jbpm, neither in the mysql-connector but a bad programming from the earlier developper of the application I am working on.
So problem solved.
Thank you for your interest.
Thanks for letting us know
Eric, Do you mind posting what the problem was so that if others have a similar issue, we may be able to find it? Thanks
Eric, Do you mind posting the problem you encountered so that others can determine if they are having the same issue? Thanks.
whoops, sorry about the double post...browser went nuts
the transition to a previously left node was in fact taken, but the task which was binded to this node was declared ended (by a taskInstance.cancel() ) as soon as we entered into the node. The default transition was immediatly fired. The SQL error came when comitting the transaction : the second node should be updated before being created (or somthing like that), that's why I had my deadlock (SQL error 1205). The deadlock prevents the transaction to be completed leading to a rollback. That's why I had the impression to stay in the same node.
I removed the cancel of the task which had no reason to be here (and modified a bit the task to have the behaviour actually wanted by the users).
I hope it may help you,
could you please share the code snippets before and after fixing the bug?
This would help me and the rest of the newbies resolving that kind of problem.
Thanks in advance.