You can't manually release locks from on-going transactions. Write-locks protects writes that you logically only intend to do, until the transaction commits or rolls back.
It might be possible to add a feature like that, but we'd have to keep the write-locks on the entities that are actually written to, or else the database would almost certainly allow conflicting transactions to commit. That would ruin someones day. -- Chris Vest System Engineer, Neo Technology [ skype: mr.chrisvest, twitter: chvest ] On 04 Jul 2014, at 13:50, ducky <[email protected]> wrote: > Thanks Chris. > > What I meant was that a read-write lock on a node when an edge is being > created felt heavy. If thats what is required for a transactional database > like neo4j, so be it. > > I understand how I can handle this in my user code (by retrying or > structuring my data differently). > > If I know the domain of my problem well, is it possible to release the locks > manually? > > Thanks > > On Friday, 4 July 2014 09:33:36 UTC+1, Chris Vest wrote: > Hi, > > This is expected behaviour for transactional databases with pessimistic > concurrency control. You usually handle this in user-code by retrying the > transaction, making sure that external side-effects, such as sending emails > and processing payments, only happen after the transaction has committed, or > as participants in a distributed transaction, e.g. two-phase commit. > > -- > Chris Vest > System Engineer, Neo Technology > [ skype: mr.chrisvest, twitter: chvest ] > > > On 04 Jul 2014, at 09:53, ducky <[email protected]> wrote: > >> Hi Chris, >> i) I do create more than 1 relationship per transaction. >> ii) As you suggest, the nodes b, c are involved in creating other >> relationships but not between each other. >> >> This is a real bummer. So in my case, creating locks on the nodes when >> creating relationships and the locks only being released at the end of the >> transaction is the source of the problem. >> >> This seems quite heavy to me and I am guessing that this has the potential >> for effecting the unmanaged extensions and even the REST API based >> transactions pretty badly in a multiprocessing environment. Is it worth >> raising on the github? >> >> Thanks a lot for your help! >> >> On Thursday, 3 July 2014 22:14:02 UTC+1, Chris Vest wrote: >> Do you create more than one relationship per transaction? Both the start and >> the end node have to be lock to create a relationship between them, and >> locks are not released until the transaction commits. It could also be that >> you have some other transaction that happens to work with the start and end >> nodes. >> >> >> -- >> Chris Vest >> System Engineer, Neo Technology >> [ skype: mr.chrisvest, twitter: chvest ] >> >> >> On 03 Jul 2014, at 18:13, ducky <[email protected]> wrote: >> >>> Hi, >>> I am using Neo4j 2.1.2 and I have an unmanaged extension in which I am >>> trying to create the following relationships in separate concurrent >>> transactions: >>> >>> 1) (b)-[:REL]->(a) >>> 2) (c)-[:REL]->(a) >>> >>> I am never deleting any relationship and I am getting this error: >>> >>> org.neo4j.kernel.DeadlockDetectedException: LockClient[118] can't wait on >>> resource RWLock[NODE(429288), hash=1375407138] since => LockClient[118] >>> <-[:HELD_BY]- RWLock[NODE(429304), hash=1035143818] <-[:WAITING_FOR]- >>> LockClient[119] <-[:HELD_BY]- RWLock[NODE(429288), hash=1375407138] >>> at >>> org.neo4j.kernel.impl.locking.community.RagManager.checkWaitOnRecursive(RagManager.java:211) >>> at >>> org.neo4j.kernel.impl.locking.community.RagManager.checkWaitOnRecursive(RagManager.java:238) >>> at >>> org.neo4j.kernel.impl.locking.community.RagManager.checkWaitOn(RagManager.java:178) >>> at >>> org.neo4j.kernel.impl.locking.community.RWLock.deadlockGuardedWait(RWLock.java:547) >>> at >>> org.neo4j.kernel.impl.locking.community.RWLock.acquireWriteLock(RWLock.java:319) >>> at >>> org.neo4j.kernel.impl.locking.community.LockManagerImpl.getWriteLock(LockManagerImpl.java:68) >>> at >>> org.neo4j.kernel.impl.locking.community.CommunityLockClient.acquireExclusive(CommunityLockClient.java:73) >>> at >>> org.neo4j.kernel.impl.api.LockingStatementOperations.relationshipCreate(LockingStatementOperations.java:215) >>> at >>> org.neo4j.kernel.impl.api.OperationsFacade.relationshipCreate(OperationsFacade.java:515) >>> at >>> org.neo4j.kernel.impl.core.NodeProxy.createRelationshipTo(NodeProxy.java:455) >>> .......(snipped)....... >>> >>> I've read the section called Deadlocks in the documentation but I don't >>> think what I am doing should lead to the deadlock. >>> >>> Any help would be appreciated. >>> >>> Thanks! >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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. -- 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.
