<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">So we still haven't discussed my biggest concern here, which is item 5) below in the list of implications. Is this performance penalty and potential for deadlocks small enough a price to pay for the correctness of concurrent access on the root node? What do people think?<DIV><BR class="khtml-block-placeholder"></DIV><DIV><DIV><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><BR class="Apple-interchange-newline"></SPAN></SPAN> </DIV><BR><DIV><BLOCKQUOTE type="cite"><DIV class="OutlookMessageHeader" lang="en-us" dir="ltr" align="left"><FONT face="Tahoma" size="2"><B>From:</B> Manik Surtani [<A href="mailto:manik@jboss.org">mailto:manik@jboss.org</A>] <BR><B>Sent:</B> Monday, November 27, 2006 7:19 PM<BR><B>To:</B> Manik Surtani<BR><B>Cc:</B> Bela Ban; Ben Wang; Brian Stansberry; Vladimir Blagojevic; Galder Zamarreno<BR><B>Subject:</B> Re: Fundamental problem with pessimistic locking<BR></FONT><BR></DIV> <DIV></DIV>Ok, this seems to work, making things a lot more 'correct'. But before I roll this into an official release and start making changes en-masse, porting this to 1.4.x and 2.0.0, I'd like to step back and think about whether this is what we really want. Here is what I've effectively done with 1.3.0.SP4, all related to pessimistic locking only: <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>a) Added a mechanism for not removing nodes when remove() is called, and instead storing them in a map which can be referenced by concurrent threads and locks attempted. (Mutated version of Brian's original fix to JBCACHE-871)</DIV> <DIV>b) When locking nodes in PLI.lock(), added a mechanism to obtain a WL on a node if the next node after it needs to be created or removed. (JBCACHE-875)</DIV> <DIV>c) Modified PLI.lock() to start with Fqn.ROOT rather than Fqn.get(0), which applies the same cache-wide locking behaviour to the root as well. Prior to this, the root never was locked for anything. </DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>The implications of these, for the sake of accuracy and correctness, are possibly:</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>1) Performance impact on inspecting nodes in b) to decide on whether WLs are needed</DIV> <DIV>2) Memory impact on maintaining a map of removed nodes in a)</DIV> <DIV>3) Reduced concurrency due to overall stronger locks in b)</DIV> <DIV>4) Much reduced concurrency because of the locking in c)</DIV> <DIV>5) Potential of more deadlocks/timeouts because of 3) and 4) above.</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Of the above, 5) manifests itself in a few unit tests that have now started to fail (TxCacheLoaderTest, some state transfer tests, etc.). Simple example, taken from one of the failing tests, leads to a deadlock:</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>1: mgr.begin();</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>2: Transaction tx=mgr.getTransaction();</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>3: cache1.put("/one/two/three", "key1", "val1");</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>4: assertNull(cache2.get("/one/two/three", "key1"));</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>5: tx.commit();</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Line 3 obtains a WL on "/" on cache1, for GTX 1</DIV> <DIV>Line 4 obtains a WL on "/" on cache2, for GTX 2</DIV> <DIV>Line 5, on replication, tries to get a WL on "/" on cache2, for GTX 1</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Both GTXs relate to the same TX since they are in the same thread. Boom, deadlock.</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>One thing here though, in my opinion, another bug in the original PLI:</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>When doing a get on a node that doesn't exist, intermediate nodes are created. E.g., cache2.get("/one/two/three", "key1") actually ends up creating /one/two/three first, and after the JBCACHE-875 fix, /, /one and /one/two will be WL'd for a get() on a nonexistent node!! Shouldn't the loop just be short-circuited such that at any point, if the next node does not exist and the lock_type requested is READ, just return a null? Saves us a whole bunch of unnecessary WL's ... </DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Sorry about the long and rambling email. Thoughts and opinions?</DIV> <DIV> <DIV><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; -khtml-text-decorations-in-effect: none; -apple-text-size-adjust: auto; orphans: 2; widows: 2"><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; -khtml-text-decorations-in-effect: none; -apple-text-size-adjust: auto; orphans: 2; widows: 2"> <DIV>--</DIV> <DIV>Manik Surtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Lead, JBoss Cache</DIV> <DIV>JBoss, a division of Red Hat</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Email: <A href="mailto:manik@jboss.org">manik@jboss.org</A></DIV> <DIV>Telephone: +44 7786 702 706</DIV> <DIV>MSN: <A href="mailto:manik@surtani.org">manik@surtani.org</A></DIV> <DIV>Yahoo/AIM/Skype: maniksurtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN></SPAN></DIV><BR> <DIV> <DIV>On 27 Nov 2006, at 10:16, Manik Surtani wrote:</DIV><BR class="Apple-interchange-newline"> <BLOCKQUOTE type="cite">Ok, take away the crap about it being a bug in the util.concurrent code. It's a bug in JBC, specifically on line 75 in TreeCache.java: <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>protected DataNode root = NodeFactory.getInstance().createDataNode(NodeFactory.NODE_TYPE_TREENODE, SEPARATOR, Fqn.fromString(SEPARATOR), null, null, this);</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>:-) The root node is initialised when new TreeCache() is called, well before isolation levels, etc. are set, which causes the root node to be created with isolation level of NONE. Hence the insane behaviour when trying to content for write locks on the root node.</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Just fixed this, running a bunch of regressions now.</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Cheers,</DIV> <DIV> <DIV><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; -khtml-text-decorations-in-effect: none; -apple-text-size-adjust: auto; orphans: 2; widows: 2"><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; -khtml-text-decorations-in-effect: none; -apple-text-size-adjust: auto; orphans: 2; widows: 2"> <DIV>--</DIV> <DIV>Manik Surtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Lead, JBoss Cache</DIV> <DIV>JBoss, a division of Red Hat</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Email: <A href="mailto:manik@jboss.org">manik@jboss.org</A></DIV> <DIV>Telephone: +44 7786 702 706</DIV> <DIV>MSN: <A href="mailto:manik@surtani.org">manik@surtani.org</A></DIV> <DIV>Yahoo/AIM/Skype: maniksurtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN></SPAN></DIV><BR> <DIV> <DIV>On 26 Nov 2006, at 19:04, Bela Ban wrote:</DIV><BR class="Apple-interchange-newline"> <BLOCKQUOTE type="cite">Forwarding to the entire group<BR><BR>Manik Surtani wrote: <BLOCKQUOTE cite="midC4FC9C0A-6EDB-4C19-894A-1487CBAFE71D@jboss.org" type="cite">Ok, boiled it down to a contention issue on locking Fqn.ROOT, which prior to JBCACHE-875, was never locked - either for reading or writing. (I do this by changing the loop in the lock() method in PLI to first consider the root before the individual Fqn elements). (This problem is also apparent in o.j.c.transaction.DeadlockTest on a multi-cpu box). <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>2006-11-26 14:58:09,566 DEBUG [Node] (Thread-2) acquiring WL: fqn=/, caller=GlobalTransaction:<null>:2, lock=<unlocked></DIV> <DIV> <snip></DIV> <DIV>2006-11-26 14:58:09,572 DEBUG [Node] (Thread-3) acquiring WL: fqn=/, caller=GlobalTransaction:<null>:3, lock=<unlocked></DIV> <DIV> <snip></DIV> <DIV>2006-11-26 14:58:09,576 DEBUG [Node] (Thread-2) acquired WL: fqn=/, caller=GlobalTransaction:<null>:2, lock=write owner=GlobalTransaction:<null>:2</DIV> <DIV> <snip></DIV> <DIV>2006-11-26 14:58:09,581 INFO [TxInterceptor] (Thread-3) There was a problem handling this request</DIV> <DIV>java.lang.IllegalStateException: there is already a writer holding the lock: GlobalTransaction:<null>:2 and caller is GlobalTransaction:<null>:3</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:101)</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:187)</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>at org.jboss.cache.Node.acquireWriteLock(Node.java:557)</DIV> <DIV><SPAN class="Apple-tab-span" style="WHITE-SPACE: pre"></SPAN>at org.jboss.cache.Node.acquire(Node.java:517)</DIV> <DIV>< snip - lots></DIV> <DIV>2006-11-26 14:58:09,850 DEBUG [Node] (Thread-2) created child: fqn=/, child_name=NODE</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>I can't understand why concurrent WL acquisition in IdentityLock.acquireWriteLock() behaves correctly for all nodes except the root node. As you can see in the log snippet above, both Thread-2 and Thread-3 call IdentityLock.acquireWriteLock (line 178) and get a 'true', and one of the threads cause an exception on line 187.</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR> <DIV><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px; orphans: 2; widows: 2"><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px; orphans: 2; widows: 2"> <DIV>--</DIV> <DIV>Manik Surtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Lead, JBoss Cache</DIV> <DIV>JBoss, a division of Red Hat</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Email: <A href="mailto:manik@jboss.org">manik@jboss.org</A></DIV> <DIV>Telephone: +44 7786 702 706</DIV> <DIV>MSN: <A href="mailto:manik@surtani.org">manik@surtani.org</A></DIV> <DIV>Yahoo/AIM/Skype: maniksurtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN></SPAN></DIV><BR> <DIV> <DIV>On 26 Nov 2006, at 13:54, Manik Surtani wrote:</DIV><BR class="Apple-interchange-newline"> <BLOCKQUOTE type="cite">I didn't want to acquire the WL immediately since it involved an additional test to check if the next node in the fqn needed creation. But I went with that algorithm in the end since the locks had problems with concurrent readers attempting to upgrade to writers. <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>So most of the regressions pass, as well as the new tests introduced, and I am very close to something working, EXCEPT one very strange problem with the IdentityLock and ConcurrentCreationDeadlockTest.testLocalCacheLoader2Modifications() - get the latest on the 1.3.0 branch for this to make any sense. The problem is between lines 178 and 187 of IdentityLock, in the acquireWriteLock() method. </DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Attempting to get a hold of a write lock returns true, but setting the writer throws an exception since another writer exists. Odd that this happens since the calling thread should have the semaphore by then, also odd that this only seems to happen in this one test which is meant to test concurrency in the CacheLoaderInterceptor. </DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>I'm still investigating, but if you have any ideas about how and why this may happen, I'd love to hear it ... :-)</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Cheers, <DIV> <DIV><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px; orphans: 2; widows: 2"><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px; orphans: 2; widows: 2"> <DIV>--</DIV> <DIV>Manik Surtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Lead, JBoss Cache</DIV> <DIV>JBoss, a division of Red Hat</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>Email: <A href="mailto:manik@jboss.org">manik@jboss.org</A></DIV> <DIV>Telephone: +44 7786 702 706</DIV> <DIV>MSN: <A href="mailto:manik@surtani.org">manik@surtani.org</A></DIV> <DIV>Yahoo/AIM/Skype: maniksurtani</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN></SPAN></DIV><BR> <DIV> <DIV>On 24 Nov 2006, at 15:25, Bela Ban wrote:</DIV><BR class="Apple-interchange-newline"> <BLOCKQUOTE type="cite"><FONT face="Arial" color="#0000ff" size="2"></FONT><BR><BR>Manik Surtani wrote: <BLOCKQUOTE cite="midBB193631-F326-48EB-B3DA-D5DE87118320@jboss.org" type="cite"> <DIV><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px; orphans: 2; widows: 2"><SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px; orphans: 2; widows: 2"></SPAN></SPAN></DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR> <DIV> <DIV>On 24 Nov 2006, at 14:44, Bela Ban wrote:</DIV><BR class="Apple-interchange-newline"> <BLOCKQUOTE type="cite"><FONT face="Arial" color="#0000ff" size="2"></FONT><BR><BR></BLOCKQUOTE> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>The first one you mentioned can lead to race conditions, depending on the order of whether the upgrade on b or the creation/WL on c happens first. What I've implemented is more like:</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>1: Acquire RL on a</DIV> <DIV>2: Acquire RL on b</DIV> <DIV>3: Identify that we need to create c.</DIV> <DIV>4: Upgrade RL on b to WL</DIV> <DIV>5: *now* create c, and acquire WL on it.</DIV> <DIV><FONT face="Arial" color="#0000ff" size="2"></FONT><BR class="khtml-block-placeholder"></DIV> <DIV>So there is a possibility that step 4 may block until other readers on b release their locks, but no one else could grab the WL since the current TX will have a RL.</DIV></DIV></BLOCKQUOTE><BR>I see. Why don't you acquire a WL on b (step 2) *immediately* rather than going through the upgrade if you know you have to acquire a WL later anyway ? You might still deadlock:<BR>2: acquire RL on b<BR>(in the meantime): some other TX acquires a RL on b, possibly upgrades to WL<BR>3: you want to acquire a WL on b and block on the other TX's RL or WL<BR><BR><PRE class="moz-signature" cols="60">--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
</PRE></BLOCKQUOTE></DIV><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE><BR><PRE class="moz-signature" cols="60">--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
</PRE></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>