<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2995" name=GENERATOR></HEAD>
<BODY
style="WORD-WRAP: break-word; khtml-nbsp-mode: space; khtml-line-break: after-white-space">
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=781560723-28112006>Hmm; thinking out loud....</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=781560723-28112006></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=781560723-28112006>If you're not doing lots of adds/removes to the level
below root, it's not a big cost, right?</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=781560723-28112006></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=781560723-28112006>And if you are doing lots of adds/removes at that
level, it's probably important to have the correct locking
behavior.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=781560723-28112006><FONT face=Arial color=#0000ff size=2>So,
seems OK to me.</FONT></SPAN><BR></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Manik Surtani [mailto:manik@jboss.org]
<BR><B>Sent:</B> Tuesday, November 28, 2006 4:58 PM<BR><B>To:</B> Ben Wang;
Bela Ban; Brian Stansberry; Vladimir Blagojevic; Galder Zamarreno;
jbosscache-dev@lists.jboss.org<BR><B>Subject:</B> Re: Fundamental problem with
pessimistic locking<BR></FONT><BR></DIV>
<DIV></DIV>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="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"><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></BLOCKQUOTE></BODY></HTML>