Lock handling has not been exposed in the real API (yet) but you can
still access the internal lock manager. Here is an example on how to
do it:
// get lock manager
LockManager lockManager = ((EmbeddedNeo)
neo).getConfig().getLockManager();
// start transaction that sometimes deadlocks with other transactions
Transaction tx = neo.beginTx();
// first thing we do is grab a write lock on something,
// for example a node (the other transactions then have to
lock on same node)
lockManager.getWriteLock( node );
// perform work that previously deadlocked
// release write lock
lockManager.releaseWriteLock( node );
// commit transaction
tx.success();
tx.finish();
There exist a "lock releaser" adding the lock to the running
transaction. The lock will then be released upon commit or rollback of
the transaction:
Transaction tx = neo.beginTx();
lockManager.getWriteLock( node );
// add write lock on node to transaction
LockReleaser lockReleaser = ((EmbeddedNeo)
neo).getConfig().getLockReleaser();
lockManager.addLockToTransaction( node, LockType.WRITE );
// perform work, lock will be released on commit/rollback
Hope this helps.
Regards,
-Johan
On Tue, Nov 3, 2009 at 12:49 AM, Andreas Guenther
<[email protected]> wrote:
> Johan,
>
> I like to consider the node lock idea. Can you provide a quick code
> snippet on the recommended approach for this?
>
> Thank you in advance,
> -Andreas
>
> Johan Svensson wrote:
>> On Mon, Nov 2, 2009 at 9:06 PM, Andreas Guenther
>> <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> I am getting the below deadlock exception occasionally and so far only
>>> on relationship operations. The code base is trunk. The system this is
>>> running on is Linux and the Java app integrates Neo with Spring
>>> transaction manager. Multiple threads are actively updating the Neo
>>> storage in different ways. The only way for us to currently mitigate
>>> this problem is to retry the entire transaction call around this, but
>>> this only succeeds to 99%. I am using the LuceneIndexer to store a
>>> simple Long ID value representing a node in case that helps based on the
>>> exception message.
>>>
>>> I am currently thinking how to best extract this problem into a little
>>> unit test but based on how often this happens, I haven't been able to
>>> reproduce it in a self-contained test suite.
>>>
>>> Any suggestions on how to get this under control?
>>>
>>>
>>
>> Hi,
>>
>> Looks like a standard deadlock, two or more transactions try to modify
>> the same data and end up in a deadlock. There are several ways to get
>> around this. I would suggest either do some external synchronization
>> at the beginning of the transaction (for example get a write lock on a
>> node so transactions will execute after each other instead of race
>> towards a potential deadlock) or modify the "node space" layout so
>> there is a lower chance of transactions waiting on each other (similar
>> to lock striping but you do it by having a different layout of the
>> graph).
>>
>> Regards,
>> -Johan
_______________________________________________
Neo mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
