-
1. Re: Exclusive lock on bottom (leaf) node only?
manik May 31, 2007 9:47 AM (in response to atijms)REPEATABLE_READ
-
2. Re: Exclusive lock on bottom (leaf) node only?
fredrikj May 31, 2007 5:30 PM (in response to atijms)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... -
3. Re: Exclusive lock on bottom (leaf) node only?
manik May 31, 2007 6:17 PM (in response to atijms)
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. -
4. Re: Exclusive lock on bottom (leaf) node only?
brian.stansberry May 31, 2007 9:51 PM (in response to atijms)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.
-
5. Re: Exclusive lock on bottom (leaf) node only?
brian.stansberry May 31, 2007 9:56 PM (in response to atijms)Oops, Manik, I didn't see your post.
-
6. Re: Exclusive lock on bottom (leaf) node only?
fredrikj Jun 11, 2007 8:51 AM (in response to atijms)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? -
7. Re: Exclusive lock on bottom (leaf) node only?
manik Jun 11, 2007 8:59 AM (in response to atijms)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.
-
9. Re: Exclusive lock on bottom (leaf) node only?
fredrikj Jun 12, 2007 7:23 AM (in response to atijms)Great stuff!