Re: [Neo4j] Re: DeadlockDetectedException

[Peter Neubauer]

Do you have the whole project somewhere? Seems there is indeed some deadlock in there. Would be nice to debug it...

/peter

Send from mobile.

On Aug 2, 2012 12:09 PM, "dizus" <diz...@gmail.com> wrote:

One little snipped is missing. Though it's pretty simple too:

    private void createTempLinks(Node from, Iterable<Node> list, Direction dir) {
        for( Node node: list ) {
            double dist = GeoCostEvaluator.distance(from, node);
            if( dir == Direction.OUTGOING ) {
                createWalkPath(from, node, dist);
            } else {
                createWalkPath(node, from, dist);
            }
        }
    }

[dizus]

No, unfortunately I dont have this project available for public access. Do you mean there's a deadlock situation going on in my application code
or is it a Neo4j issue? I didnt quite catch it. The code seems to be absolutely straightforward and trivial - this is what bothers me. For this moment
I've solved the problem by wrapping findMultipleRoutes() method in synchronized block. But shouldn't transaction isolation do the trick? I mean, when
one thread creates the temporary nodes and links them to the main graph and do the dijkstra search, shouldn't the other threads see the unmodified
version of the graph? Probably I'm missing something.

Dmitry.

On Thursday, August 2, 2012 3:15:46 PM UTC+4, Peter Neubauer wrote:

Do you have the whole project somewhere? Seems there is indeed some deadlock in there. Would be nice to debug it...

/peter

Send from mobile.

One little snipped is missing. Though it's pretty simple too:

[Mattias Persson]

If you have multiple threads simultaneously locking random parts of the graph they can end up in a scenario where a wait to get a lock would result in deadlock between two or more threads, it's perfectly normal.

What you would best want to do here is to either change your access patterns to prevent this scenario, or wrap each transaction in a retry loop until it succeeds. Having a synchronized block works, but is way over-protective and could affect performance too much.

2012/8/2 dizus <diz...@gmail.com>

--
Mattias Persson, [mat...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

[Dmitry Bakhvalov]

Thanx for your reply. Unfortunatelly I can't control access pattern as
it is user-generated. But I'm gonna test the retry loop, as you
suggested.

> --
>
>