Even without the synchronized ( _lock ) block your transactions would be
"serialized" as each transaction would have to grab a lock on that factory
node. So I propose you change that method implementation to:

   private long generateId()
   {
       // This is a workaround for grabbing a write lock explicitly
       _factoryNode.removeProperty(
"non-existent-property-just-for-locking" );

       Long id;

       if (_factoryNode.hasProperty("idseq"))
       {
           id = (Long) _factoryNode.getProperty("idseq");
       }
       else
       {
           id = 1L;
       }
       _factoryNode.setProperty("idseq", id+1);
       return id;
   }


2011/11/2 Cres <[email protected]>

> Hi David,
>
> Thank you very much for your response. I can see now what caused the
> deadlock.
>
> However, I'm not really sure how I can solve this problem efficiently - as
> you mentioned, your proposed solution will effectively serialize my
> transactions. Unfortunately, it'd be very difficult for me to split each
> transaction into two in the application I'm currently working on (the code
> I
> posted in the first message was just a sample code I wrote to explain the
> problem more clearly) since there are many transactions which are "higher
> up
> the chain" and are not really nearby the node factory, which is where I
> want
> to use your lock-grabbing technique.
>
> I thought about creating a nested transaction just for the update for the
> factory node's "idseq" property, after which I'd commit (and thereby
> release
> the RW lock I grabbed when removing the non-existing property), but I now
> realize it can't work because nested transactions aren't "pure nested" and
> so the lock would remain until the parent transaction commits...
>
> Is there any way I could possibly release the lock I have for the node
> without committing the entire transaction? And since I presume such a way
> doesn't exist, do you happen to know of any other possible solutions for my
> problem?
>
> Thanks again,
> Ran.
>
> --
> View this message in context:
> http://neo4j-community-discussions.438527.n3.nabble.com/Node-Id-generation-deadlock-tp3473118p3474747.html
> Sent from the Neo4j Community Discussions mailing list archive at
> Nabble.com.
> _______________________________________________
> Neo4j mailing list
> [email protected]
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [[email protected]]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to