On Mon, Sep 26, 2011 at 2:28 AM, Bryce <bryc...@gmail.com> wrote:
> Is there any reason that access to the lock manager is a little difficult?
> Is there any issue with using it (both single server and HA)? Are their
> any issues to look out for? And does the above code look workable?
>
The reason the LockManager is "hidden away" is because it is considered an
implementation detail.
We reserve the right to change it at any point without prior notice.
>From one version to another, the API of this class could potentially look
completely different, or have very different semantics.
If you write code that depend on implementation internal classes it will at
best cause you compilation errors when upgrading to a later version of
Neo4j, at worst break in subtle ways after you've deployed your application.
There is another important thing to note about your sample code:
On Mon, Sep 26, 2011 at 2:28 AM, Bryce <bryc...@gmail.com> wrote:
>
> private void acquireLock( LockType lockType )
> {
> GraphDatabaseService graphDb = baseNode.getGraphDatabase();
> if ( lockType == LockType.READ && graphDb instanceof
> AbstractGraphDatabase )
> {
> ((AbstractGraphDatabase)
> baseNode.getGraphDatabase()).getConfig().getLockManager().getReadLock(
> baseNode );
> }
> else {
> // default to write lock if read locks unavailable
> baseNode.removeProperty( "___dummy_property_to_acquire_lock___"
> );
> }
> }
>
The two different code paths in this code have very different semantics. The
first path (if it is a read lock and the db is and AbstractGraphDatabase)
will acquire a read lock and hold it indefinitely. The second path will try
to remove a dummy property, resulting in a write lock that gets tied to the
current transaction, and thus gets released when the transaction completes.
There is another class involved in the lock management in Neo4j, it is
called LockReleaser. All locks that are acquired through the public APIs are
registered with the LockReleaser. This will tie the lock to the transaction
to ensure that the lock is released when the transaction completes. If the
lock is only acquired through the LockManager, and not registered with the
LockReleaser, you need to manually release the lock.
The reason for the remove-non-existing-property-hack is that we haven't
decided on a good public API for lock management. The questions around this
are:
* Should there be release() methods for locks as well? or should locks
always be tied to the transaction?
* Where should the methods live? On the entities themselves? i.e.
node.acquireReadLock() / node.aquireWriteLock() or on the Transaction object
to signal that locks are tied to the life cycle of the transaction? i.e.
tx.readLock(node) / tx.writeLock(node)
Cheers,
--
Tobias Ivarsson <tobias.ivars...@neotechnology.com>
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857 (Swe); +1 650 450 3806 (US)
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
