[Jdbm-developer] MC-DataSafe (in Persistent Store Interface).

All,
I would appreciate some perspectives into [1] in the section in which
MC-DataSafe is discussed. It appears on page 24 (as numbered on the
document) that the notion of handling concurrency control at the object
layer and simplifying it at the DBCache layer is advocated. However in
the middle of the next page, it appears that this is critiqued.
> By placing concurrency control at the top of the Flask layered
> architecture, opportunities for exploiting the synergy between
> recovery and concurrency control [Agrawal and DeWitt 1985; Alonso et
> al. 1994; Feeley et al. 1994] are missed, and to the extent that the
> storage layer replicates pages, a duplication of effort is introduced
> on account of the coherency mechanisms necessary within the storage
> layer.
It may be that this critique was only meant to apply in the context of
a distributed store, but I would like to understand this issue more as
we are discussing a similar layering.
I will chase some of the references and see if that sheds any more light.
-bryan
[1] http://citeseer.ist.psu.edu/187029.html

Thread view

All,
I would appreciate some perspectives into [1] in the section in which
MC-DataSafe is discussed. It appears on page 24 (as numbered on the
document) that the notion of handling concurrency control at the object
layer and simplifying it at the DBCache layer is advocated. However in
the middle of the next page, it appears that this is critiqued.
> By placing concurrency control at the top of the Flask layered
> architecture, opportunities for exploiting the synergy between
> recovery and concurrency control [Agrawal and DeWitt 1985; Alonso et
> al. 1994; Feeley et al. 1994] are missed, and to the extent that the
> storage layer replicates pages, a duplication of effort is introduced
> on account of the coherency mechanisms necessary within the storage
> layer.
It may be that this critique was only meant to apply in the context of
a distributed store, but I would like to understand this issue more as
we are discussing a similar layering.
I will chase some of the references and see if that sheds any more light.
-bryan
[1] http://citeseer.ist.psu.edu/187029.html

<!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>Bryan-</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>My initial pass
at this is that the criticism does apply
primarily in the context of a distributed
store.&nbsp; I suspect (without reading in
great detail) that there are&nbsp;layers
between the concurrency control layer (at
the top of their stack) and the low level
atomic commit layer that inhibit recovery
(most likely, these layers are related to
the distributed nature of the store).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>That said, I
haven't read this in great detail, so I could
be off.&nbsp; I would need to have a good
example of what types of opportunities are
lost before I could really say whether this
applies to our discussion so far or not -
were there any other details in the paper
that hinted at what those may have been?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thanks!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>- K</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;</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>&gt;
All,<BR><BR>I would appreciate some perspectives
into [1] in the section in which<BR>MC-DataSafe
is discussed. &nbsp;It appears on page 24
(as numbered on the<BR>document) that the
notion of handling concurrency control at
the object<BR>layer and simplifying it at
the DBCache layer is advocated. &nbsp;However
in<BR>the middle of the next page, it appears
that this is critiqued.<BR><BR>&gt; By placing
concurrency control at the top of the Flask
layered<BR>&gt; architecture, opportunities
for exploiting the synergy between<BR>&gt;
recovery and concurrency control [Agrawal
and DeWitt 1985; Alonso et<BR>&gt; al. 1994;
Feeley et al. 1994] are missed, and to the
extent that the<BR>&gt; storage layer replicates
pages, a duplication of effort is introduced<BR>&gt;
on account of the coherency mechanisms necessary
within the storage<BR>&gt; layer.<BR><BR>It
may be that this critique was only meant
to apply in the context of<BR>a distributed
store, but I would like to understand this
issue more as<BR>we are discussing a similar
layering.<BR><BR>I will chase some of the
references and see if that sheds any more
light.<BR><BR>-bryan<BR><BR>[1] <A href="http://citeseer.ist.psu.edu/187029.html"><FONT
color=#0000ff>http://citeseer.ist.psu.edu/187029.html</FONT></A><BR><BR><BR>-------------------------------------------------------<BR>This
SF.net email is sponsored by: Splunk Inc.
Do you grep through log files<BR>for problems?
&nbsp;Stop! &nbsp;Download the new AJAX search
engine that makes<BR>searching your log files
as easy as surfing the &nbsp;web. &nbsp;DOWNLOAD
SPLUNK!<BR><A href="http://sel.as-us.falkag.net/sel?cmd=lnk&amp;kid=103432&amp;bid=230486&amp;dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&amp;kid=103432&amp;bid=230486&amp;dat=121642</FONT></A><BR>_______________________________________________<BR>Jdbm-developer
mailing list<BR><A href="mailto:Jdbm-developer@..."><FONT
color=#0000ff>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>&lt;<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML&gt;