Exclusive lock on bottom (leaf) node only?

[atijms]

Hi,

I'm in a situation where I would like to have an exclusive lock on only the leaf node in a tree.

E.g. suppose I have a tree with entries "/a/b/n1" and "/a/b/n2". When Tx1 accesses "/a/b/n1", Tx2 should not be able to also access (either read or write) "/a/b/n1" until Tx1 has completed and released its locks. However, meanwhile Tx3 should be able to access "/a/b/n2".

With isolation level SERIALIZABLE, the entire tree is exclusively locked. E.g. when Tx1 in the above example accesses "/a/b/n1" and writes to n1, it has a read lock on a and b and a write lock on n1. If meanwhile Tx3 wants to access "/a/b/n2", it already fails to acquire the read lock on "/a", making it impossible to reach "/a/b" and "a/b/n2"

The lower isolation levels also don't work for my usecase. E.g. when Tx1 accesses "/a/b/n1" and reads n1, Tx2 is also able to read n1 at the same time, which is what should not be allowed.

In short, I would like to be able to have SERIALIZABLE semantics per specific sub-tree instead of the whole tree.

Is something like that possible with JbossCache?

[manik]

REPEATABLE_READ

[fredrikj]

Using repeatable read as transaction isolation will not stop concurrent read access to the node if i'm not mistaken.

My interpretation is that atijms want to get an exclusive lock on '/a/b/n1' regardless of read or write operation. If this is correct then repeatable_read would not solve the issue.

I have actually the same requirement, I need to access a node and lock that node (and that node only) excusively. I do not want to write-lock the parent nodes. If I use Option.setForceWriteLock() , then all nodes are write locked.

So far, I have found two working solutions, none which are pretty imho.

1. Perform a write operation such as remove(...) first when accessing the node. That acquires a write lock during the transaction right away. Not very performance wise I would gather though =)

2. Make your own locking scheme. I implemented this, it doesn't feel right (feels like a true hack), but it works for me. First I get the lock from the node, add the lock to my transaction. Then I acquireAll on the node for read locks and finally acquire write lock on the leaf node only.

I'd be real happy if there was an option we could provide (similar to Options.setForceWriteLock()) that let us readlock the branch and write lock the leaf node only...

[manik]

My interpretation is that atijms want to get an exclusive lock on '/a/b/n1' regardless of read or write operation. If this is correct then repeatable_read would not solve the issue.

Yes, if this is the case then R_R won't help.

Option.setForceWriteLock() should only acquire a WL on the target node (leaf). If it does so for every parent node as well, then this is a bug.

[brian.stansberry]

The use case you describe sounds like what IIRC Option.forceWriteLock was meant for; kind of a SELECT FOR UPDATE semantic. Not sure if it needs to lock all the nodes on the way down (it definitely does). I'd think not for the usages I've thought about, but haven't thought about it hard.

[brian.stansberry]

Oops, Manik, I didn't see your post.

[fredrikj]

What is the status of this?

Should Option.setForceWriteLock() write-lock all nodes all the way up from the designated node or not?

If this is in fact correct behaviour, is there any recommended way of solving the leaf-only locking scenario described in this thread?

[manik]

The option should not force WLs all the way to the leaf - it should only be forced on the leaf. Will create a JIRA for this shortly.

[manik]

http://jira.jboss.com/jira/browse/JBCACHE-1102

[fredrikj]

Great stuff!