Menu
▾
▴
re[4]: [Jdbm-developer] MC-DataSafe
|
From: 'Kevin D. ' <ke...@tr...> - 2006-02-16 23:36:26
|
<!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>Maybe you can
help - can you explain to me how MVCC could
have anything to do serializability of transactions?
Am I completely off-base in saying that adding
read locking to MVCC would defeat the purpose?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I'm obviously
having a massive disconnect.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks,</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> </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=blue>>
Kevin,<BR><BR>MVCC does provide serializability.
The tradeoffs among correct<BR>concurrency
control mechanisms involve performance not
correctness.<BR>The problems with performance
for MVCC are that, by itself, it tends<BR>to
produce more transaction restarts and lower
overall transaction<BR>throughput when compared
to 2PL. Postgres is some sort of hybrid<BR>of
2PL and MVCC. I tried their chat group
yesterday to get some<BR>insight into exactly
what kind of a hybrid, but no one could say
"Oh,<BR>we implemented XYZ".<BR><BR>I do
not think that MVCC (or any hybrid of MVCC)
is a silver bullet<BR>for performance. Neither
postgres nor Oracle is a clear performance<BR>winner
-- in fact I have personal experience with
the one of these<BR>platforms which places
it an order of magnitude slower than jdbm
for<BR>our application (an semantic web store)
using a solution developer by<BR>the database
people themselves.<BR><BR>I recommend a closer
reading of this paper. I have found
later articles<BR>which use analytic techniques
to examine the performance of a variety of<BR>concurrency
control mechanisms, but none which benchmarks
real databases<BR>explicitly in terms of
this issue. Perhaps we could look at
some of the<BR>RDBMS benchmark literature
for some insight there?<BR><BR>Enjoy your
vacation,<BR><BR>-bryan<BR><BR>-----Original
Message-----<BR>From: <A href="mailto:jdb...@li..."><FONT
color=#0000ff>jdb...@li...</FONT></A><BR>To:
JDBM Developer listserv<BR>Sent: 2/16/2006
4:48 PM<BR>Subject: re[2]: [Jdbm-developer]
MC-DataSafe <BR><BR>Bryan-<BR><BR>Can you
please provide a description of how MVCC
(with non-serialized<BR>processing of transactions)
would cause either of the two lost data/bad<BR>data
examples described in the paper?<BR><BR>The
way I read your email, it sounds like you
are implying that MVCC<BR>can't provide transaction
isolation or atomic updates, when it<BR>absolutely
does. MVCC just operates optimistically
in these situations.<BR>Under MVCC in the
first example, an abort would occur. In
the second<BR>example under MVCC, the report
created in T2 would be correct, and T1<BR>would
commit without problems. In either
case, nothing gets left on the<BR>floor...<BR><BR>The
massive advantage of MVCC comes in the second
example: If the<BR>report required
a significant amount of time to complete
(it was reading<BR>a huge number of rows),
then serializing the transactions as described<BR>in
the paper will cause massive slow downs for
the poor sucker who is<BR>trying to execute
T1 (and kill concurrency). In MVCC,
the update would<BR>happen immediately and
return, even if T2 takes a long time to complete.<BR>This
absolutely maximizes concurrency, and is
perfectly safe.<BR><BR><BR>I'm going to need
some serious convincing with concrete examples
before<BR>I'm willing to favor serializable
transactions over MVCC's approach. My<BR>concern
at this stage is that much of the literature
on these topics<BR>either doesn't account
for the radical departure from the norm that
MVCC<BR>is, or it is incorrect in it's description
of how MVCC actually operates<BR>in practice.<BR><BR>I
actually find it humorous that the concurrency
control paper we are<BR>talking about here
says that "the problem for nondistributed
DMBSs is<BR>well understood... and
one approach called two-phase locking has
been<BR>accepted as a standard solution."
That may have been true in 1981 when<BR>the
paper was published, but the good folks at
PostgreSQL and others<BR>have pretty much
blown that out of the water.<BR><BR>This
means that any broad claims made in these
older papers have to be<BR>taken with a considerable
grain of salt, and evaluated in the context
of<BR>the new development of MVCC. Bernstein
and Goodman are certainly going<BR>to say
that 2 phase locking is the only way to go
- they weren't even<BR>aware that a better
approach was possible.<BR><BR>Anyway - I'm
going to be gone until the 28th - hopefully
you and Alex<BR>can continue the discussion
with vigour while I'm gone!<BR><BR>Cheers,<BR><BR>-
K<BR><BR><A href="http://www-static.cc.gatech.edu/classes/AY2003/cs8803i_fall/ConcurrencyC"><FONT
color=#0000ff>http://www-static.cc.gatech.edu/classes/AY2003/cs8803i_fall/ConcurrencyC</FONT></A><BR>ontrol.pdf<BR><A
href="http://www-static.cc.gatech.edu/classes/AY2003/cs8803i_fall/Concurrency"><FONT
color=#0000ff><http://www-static.cc.gatech.edu/classes/AY2003/cs8803i_fall/Concurrency</FONT></A><BR>Control.pdf>
<BR> <BR> >
I have to say that I favor serializable transactions
-- at<BR>least in the<BR>abstract. Non-serializable
transactions can leave things on the floor.<BR>If
you do not have a concrete application you
don't know what that might<BR>be. Two
classic examples of problems with not enforcing<BR>serializablility<BR>are
given at the start of the paper, e.g., a
lost deposit into a bank<BR>account.<BR><BR>-bryan<BR><BR>-----Original
Message-----<BR>From: Alex Boisvert <A
href="mailto:boi...@in..."><FONT
color=#0000ff><mailto:boi...@in...></FONT></A><BR><A
href="mailto:boi...@in..."><FONT
color=#0000ff>[mailto:boi...@in...]</FONT></A><BR>Sent:
Thu 2/16/2006 11:55 AM<BR>To: Thompson, Bryan
B.<BR>Cc: 'Kevin Day '; <A href="mailto:jdb...@li..."><FONT
color=#0000ff><mailto:jdb...@li...></FONT></A><BR><A
href="mailto:jdb...@li..."><FONT
color=#0000ff>'jdb...@li...</FONT></A>
'; '''JDBM<BR>Developer listserv ' ' '<BR>Subject:
Re: [Jdbm-developer] MC-DataSafe (in Persistent
Store Inte<BR>rface).<BR><BR><BR>I agree
with figure 11 if you want to guarantee a
completely<BR>serializable history. However,
you can relax the isolation with MVCC to<BR>allow
such ordering to happen, which won't guarantee
complete<BR>serializability but in most cases
will result in a consistent outcome.<BR><BR>The
need to balance concurrency and consistency
is satisfied by most<BR>databases by offering
different levels of isolation (read uncomitted,<BR>read
committed, repeatable read, serializable,
...)<BR><BR>alex<BR><BR><BR>Thompson, Bryan
B. wrote:<BR><BR>>I think that we probably
need to be much more concrete. However
MVCC<BR>>does NOT permit a write to create
a version which would pre-date a<BR>>version
which had already been read by another tx.
Intuitively such a<BR>>write would
mean that the read had accessed the incorrect
version.<BR>This<BR>>is the subject of
figure 11 in [1]. Are we disagreeing
about the<BR>meaning<BR>>of figure 11?<BR>><BR>>-bryan<BR>>
<BR>><BR><BR><BR><BR>-------------------------------------------------------<BR>This
SF.net email is sponsored by: Splunk Inc.
Do you grep through log<BR>files<BR>for problems?
Stop! Download the new AJAX search
engine that makes<BR>searching your log files
as easy as surfing the web. DOWNLOAD
SPLUNK!<BR><BR><A href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=12164"><FONT
color=#0000ff><http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=12164</FONT></A><BR>2><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642</FONT></A><BR>_______________________________________________<BR>Jdbm-developer
mailing list<BR><A href="mailto:Jdb...@li..."><FONT
color=#0000ff><mailto:Jdb...@li...></FONT></A><BR><A
href="mailto:Jdb...@li..."><FONT
color=#0000ff>Jdb...@li...</FONT></A><BR><A
href="https://lists.sourceforge.net/lists/listinfo/jdbm-developer"><FONT
color=#0000ff><https://lists.sourceforge.net/lists/listinfo/jdbm-developer></FONT></A><BR><A
href="https://lists.sourceforge.net/lists/listinfo/jdbm-developer"><FONT
color=#0000ff>https://lists.sourceforge.net/lists/listinfo/jdbm-developer</FONT></A><BR><BR><<BR> <BR>-------------------------------------------------------
This SF.net<BR>email is sponsored by: Splunk
Inc. Do you grep through log files for<BR>problems?
Stop! Download the new AJAX search engine
that makes searching<BR>your log files as
easy as surfing the web. DOWNLOAD SPLUNK!<BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642</FONT></A><BR>_______________________________________________
Jdbm-developer mailing<BR>list <A href="mailto:Jdb...@li..."><FONT
color=#0000ff>Jdb...@li...</FONT></A><BR><A
href="https://lists.sourceforge.net/lists/listinfo/jdbm-developer"><FONT
color=#0000ff>https://lists.sourceforge.net/lists/listinfo/jdbm-developer</FONT></A><BR><BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML>
|