So far it's deadlock detection is pretty good it uses a graph internally to do that (find cycles).
Do you think you could reproduce the situation somehow Michael > Am 30.03.2015 um 15:44 schrieb Matias Burak <[email protected]>: > > Could it be possible that neo4j is not detecting a deadlock with more than 2 > threads? > I mean this case: thread-1 needs something from thread-2 which needs > something from thread-3 which needs something from thread-1. > > >> El 27/3/2015, a las 16:07, Michael Hunger <[email protected] >> <mailto:[email protected]>> escribió: >> >> >>> Am 27.03.2015 um 17:24 schrieb Matias Burak <[email protected] >>> <mailto:[email protected]>>: >>> >>> Thanks for your response. >>> Yeah, it seems that transactions might not be closed. Why would this >>> happen? I mean... I’m doing my transactions on a Spring TransactionTemplate >>> execute. >> >> Good question, don't know where the leak would come from. >> Do you perhaps execute cypher or index queries without exhausting the >> results or calling .close on them? >> >> But your stack traces should give you a hint. >> >>> Do I need neo4j enterprise to check open transacctionn with JMX? >> >> Yes >> >>> A thread-dump look like this: >>> >>> "pool-11537-thread-1" prio=5 tid=0x00007f930b395800 nid=0x1a36f in >>> Object.wait() [0x000000013c924000] >>> java.lang.Thread.State: WAITING (on object monitor) >>> at java.lang.Object.wait(Native Method) >>> - waiting on <0x00000006d6669c88> (a >>> org.neo4j.kernel.impl.transaction.RWLock) >>> at java.lang.Object.wait(Object.java:503) >>> at >>> org.neo4j.kernel.impl.transaction.RWLock.deadlockGuardedWait(RWLock.java:652) >>> at >>> org.neo4j.kernel.impl.transaction.RWLock.acquireWriteLock(RWLock.java:344) >>> >>> nid=0x1a36f is the nid on the db? There’s no nid 107375 (decimal for >>> 0x1a36f) >> >> >>> >>> >>>> El 27/3/2015, a las 12:54, Michael Hunger >>>> <[email protected] >>>> <mailto:[email protected]>> escribió: >>>> >>>> Hi Matias, please send questions like that to the google group. >>>> >>>> A deadlock appears when it is about to acquire two locks in reverse order. >>>> >>>> What you see is probably just a lock that is not released because the >>>> transaction which created it was not closed and is still running? >>>> >>>> You can check via JMX if there is still an ongoing open transaction and >>>> open locks. >>>> >>>> Also when you take a thread-dump you see what lock (incl. node-id) the >>>> thread is waiting for. >>>> >>>> Cheers, Michael >>>> >>>> On Fri, Mar 27, 2015 at 4:07 PM, Matias Burak <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi Michael, sorry I bother you again with another problem. >>>> >>>> Is it possible that Neo4j doesn’t realize that it’s in a deadlock? I’m >>>> using an old version of the db (1.9) and when running several transactions >>>> on different threads against the db sometimes the threads get locked and >>>> never are released and I don’t see an exception, they are just stuck on >>>> deadlockGuardedWait(). >>>> I expect deadlocks and I built a retry feature to try again, but I’m not >>>> getting any exceptions :( (sometimes I am) >>>> Any idea? >>>> >>>> Thanks, >>>> MAtias. >>>> >>>> >>>> >>> >> > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
