Menu
▾
▴
re[2]: [Jdbm-developer] 2PL: transactions, threads and locking (rese nd!)
|
From: Kevin D. <ke...@tr...> - 2006-03-28 01:45:51
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR,
MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT
face=Tahoma>
<DIV><FONT face=Arial size=2>Alex-</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>Interesting.
Does this imply that there can only be one
executing Tx per thread at any given point
in time? I think this starts to break
down, though, because you can't release the
locks when you suspend a Tx (not without
viloating 2PL, anyway).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>No matter what
Bryan does, he still has to deal with the
fact that a single thread could wind up needing
to block itself (by definition, this would
be deadlock). This scenario is pretty
easy to detect, and should probably abort
one of the transactions (it implies that
the application developer has not designed
their threading/transaction handling properly).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>For what it's
worth, this exact scenario happens in file
system locking where the same resource is
refered to be different handles...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I don't think
that it's appropriate to just say that only
one transaction can execute per thread, though
- as far as I can see, that doesn't really
help things unless you also say that a transaction
in that thread must finish before another
tx can be started by that thread. And
going down that path absolutely kills the
use of jdbm2 by high concurrency non-blocking
IO systems...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>To answer Bryan's
question: In the scenario he describes,
no blocking would occur. This is a
deadlock condition, and one of the transactions
would abort.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>To summarize:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I'm perfectly
cool saying that a given transaction can
only belong to a single thread at a time
(in fact, I think this encourages good programming
practices). I do *not* however, think
that the reverse should be true (i.e. a single
thread only has one active transaction at
a time). Suspend/resume helps to provide
a mechanism for the former (basically, it
is an explicit mechansim for allowing thread
context switches of a given tx) - but
it doesn't really help anything for
the later... We could certainly force
the user to suspend a tx in order to start
working on another in the same thread, but
I don't think that this buys us anything
- we still have to hold the locks (for 2PL),
so you still wind up in a 'thread must block
itself' situation.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Given that the
suspend/resume operations aren't gaining
us anything, I'd prefer to not require them
for simultaneous execution of multiple transactions
by a single thread.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I think doing
otherwise is akin to setting an effectively
global variable (the thread local transaction),
when it may make more sense just to pass
the transaction into the call... I
always look long and hard at use of a global
like this to make sure that it's justified,
and I'm not convinced (now that I'm thinking
about it - I know I said otherwise in my
last post), that it is justified in the current
situation...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- K</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> </FONT>
<TABLE>
<TBODY>
<TR>
<TD width=1 bgColor=blue><FONT face=Arial
size=2></FONT></TD>
<TD><FONT face=Arial size=2><FONT color=red>>
Thompson, Bryan B. wrote: <BR><BR>However,
given that the requirement for transaction
!= thread is motivated, I have questions
about the impact on the synchronization logic.
For example, given: <BR> <BR>Thread
t1=., t2 =; // some threads. <BR>Transaction
tx1 = , tx2 = .; // some transactions. <BR>Queue
r1 = ; // queue for resource R1. <BR> <BR>[t1
is executing tx1; t2 is executing tx2]. <BR> <BR>[
thread t1 ] r1.lock( tx2, X ); // t1 requests
a lock for tx2 on resource r1 in exclusive
mode. <BR> <BR>What happens? If
the lock can not be granted immediately,
does t1 block? There is absolutely
no way to immediately block t2. Java
synchronization does not provide for this
as far as I can tell. How do you support
blocking a transaction if a transaction is
not bound to a thread at least for
the moment? <BR>I don't think this should
be allowed because thread t1 is not associated
by tx2. That's why I don't think
passing the transaction as part of the request
makes sense.<BR><BR>alex<BR><BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML>
|