<!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> </DIV>
<DIV><FONT face=Arial size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>I've read the
two referenced articles at length and understand
where they are coming from. The lock
granularity discussion really only applies
to large multi-level data structures (for
example, if you were doing page then row
level locking in a traditional database design).
I'm not sure that hierarchecal locks will
come into play much in jdbm because we already
have direct access at the record level.
Perhaps it applies more to primary key organization
of data...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I'm interested
in hearing your proposal on how this concept
would be used in jdbm...</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>
<TABLE>
<TBODY>
<TR>
<TD width=1 bgColor=blue><FONT face=Arial
size=2></FONT></TD>
<TD><FONT face=Arial size=2><FONT color=red>>
Kevin,<BR><BR>Yes, I saw that also. I
also did some digging on the postgres IRC.
<BR>Nobody was able to flatly state the manner
in which postgres used<BR>2PL and MVCC, but
it was clear that it does both.<BR><BR>I
have been looking at support for 2PL based
on [1]. This supports<BR>some flexible
notions of hierarchical locks (intention
locks). I <BR>also have some references
on efficient deadlock detection, including<BR>an
early algorithm by Bayer [2]. (Bayer is one
of the DBCache authors.<BR>I focused on this
paper since the DBCache article cites it
as describing<BR>"sophisticated" locking
techniques which are compatible with the
DBCache<BR>architecture. It actually
looks like a minor variation on Gray in [1].)<BR><BR>I
also have a few more recent articles on online
deadlock detection<BR>algorithms. Overall
this problem looks managable.<BR><BR>The
use of hierarchical locking in [1] or [2]
was designed to reduce the<BR>#of locks that
an application needed to acquire by having
implicit locks.<BR>So you could lock an ancestor
in the hierarchy in S (share) mode for read<BR>and
another transaction could obtain a concurrent
lock in SIX (share <BR>intention exclusive).
The reads would be concurrent, but
the 2nd tx<BR>would have to wait for the
first to complete before obtaining X locks<BR>for
updates.<BR><BR>So, I think that exploring
2PL in some more depth and planning for "how<BR>could
we integrate this" makes sense. And
I still need to read through<BR>your MVCC
posts in depth.<BR><BR>-bryan<BR><BR>[1]
J.N. Gray, R.A. Lorie, G.R. Putzolu, I.L.
Traiger.<BR> Granularity
of Locks and Degrees of Consistency in a
Shared Data<BR> Base.<BR> <A
href="http://www.seas.upenn.edu/~zives/cis650/papers/granularity-locks.pdf"><FONT
color=#0000ff>http://www.seas.upenn.edu/~zives/cis650/papers/granularity-locks.pdf</FONT></A><BR><BR>[2]
Bayer, R. 1976. Integrity, Concurrency, and
Recovery in<BR> Databases.
In Proceedings of the Proceedings of the
1st European<BR> Cooperation
in informatics on ECI Conference 1976 (August
09 - 12,<BR> 1976). K. Samelson,
Ed. Lecture Notes In Computer Science,<BR> vol.
44. Springer-Verlag, London, 79-106.<BR> <A
href="http://portal.acm.org/citation.cfm?id=647864.736638"><FONT
color=#0000ff>http://portal.acm.org/citation.cfm?id=647864.736638</FONT></A><BR><BR><BR>-----Original
Message-----<BR>From: <A href="mailto:jdbm-developer-admin@...
color=#0000ff>jdbm-developer-admin@...:
JDBM Developer listserv<BR>Sent: 3/2/2006
10:39 AM<BR>Subject: re[6]: [Jdbm-developer]
Optimistic CC<BR><BR>Bryan-<BR><BR>hmmm -
how interesting... I found the following:<BR><A
href="http://db.cs.berkeley.edu/cs262/lecs/pgstorage.html"><FONT
color=#0000ff>http://db.cs.berkeley.edu/cs262/lecs/pgstorage.html</FONT></A><BR><A
href="http://db.cs.berkeley.edu/cs262/lecs/pgstorage.html"><FONT
color=#0000ff><http://db.cs.berkeley.edu/cs262/lecs/pgstorage.html></FONT></A>
and from what<BR>that article
says, it does sound like they use 2PL for
CC (and have<BR>versions for recovery - probably
for VLR isolation and recovery only).<BR>I
suspect that MVCC is used for high performance
read-only tx as well<BR>(more on that below).
This, however, completely invalidates
the<BR>description at<BR><A href="http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html"><FONT
color=#0000ff>http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html</FONT></A><BR><A
href="http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html"><FONT
color=#0000ff><http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html></FONT></A>
<BR><BR><BR>At this stage, I'm not sure what
to say. The MVCC strategy with OID/EID<BR>marking
that I outlined last night should provide
a CC layer that<BR>completely eliminates
rw conflicts. That leaves us with the
question of<BR>whether it is best to handle
ww conflict via rollback at w-w conflict
or<BR>locking and blocking on all touched
records. The good news is that it<BR>should
be relatively easy to provide for both options.
If 2PL is<BR>enabled, then reads will
grab read-locks. If it isn't enabled,
then<BR>reads won't grab read locks (read
locks will be s serious performance<BR>hit
because there are so darned many of them).
That can be done without<BR>adding
a great deal of complexity to the lock manager,
so what the heck.<BR><BR>As an added option,
I believe that it is safe to say that a read
only<BR>transaction is safe under MVCC only.
Therefore, we could have the<BR>creation
of a transaction allow the programmer to
specify read-only, at<BR>which point, the
2PL semantecs would be ignored for just that
tx.<BR><BR><BR>In terms of relative performance
of the two methods, I predict the<BR>following:<BR><BR>1.
In a properly designed system (that
uses application level<BR>synchronization
mechanisms properly), the occurances of w-w
conflicts<BR>will be quite low. In
these implementations, disabling 2PL will
provide<BR>massive performance bennefits.<BR><BR>2.
In a poorly designed system that does
wind up with lots of w-w<BR>conflicts, 2PL
will perform better - but there will still
be a lot of<BR>roll-backs b/c of deadlocks.<BR><BR>The
long and short is that the absolute best
layer to maximize<BR>concurrency of application
records is at the application level itself<BR>with
thread synchronization constructs on the
objects themselves. This<BR>is a very
natural extension of standard multi-threaded
programming.<BR>Using the database only for
concurrency management will always result
in<BR>worse performance because the database
does not have visibility of the<BR>interaction
between records - that means that it must
assume the worst<BR>and block/abort as though
all records interact equally.<BR><BR><BR>Next
steps? Here's what I'm thinking:<BR><BR>The
biggest complexity in the lock manager is
lock contention<BR>resolution. Under
pure MVCC, lock contention (which will be
for w-w<BR>locks only) will be resolved by
aborting one of the contending tx. If<BR>2PL
is active, then contention is handled by
blocking, as long as there<BR>is no deadlock.
If there is deadlock, then one of the
tx must be<BR>aborted.<BR><BR>Obviously,
contention resolution under pure MVCC is
much simpler to<BR>implement. Deadlock
detection requires a fair amount of accounting<BR>overhead
and computation - If we are going to support
2PL as an option,<BR>then we need to understand
how dealock detection is going to operate
in<BR>jdbm2, so it's probably time for Bryan
to break out his awesome research<BR>skills
and give us some concepts to noodle on :-)<BR><BR>Because
2PL may be desirable in some situations,
I think it's worth<BR>making sure that the
lock manager contains sufficient information
to<BR>allow dead-lock detection.<BR><BR>If
we can agree that we want to have the ability
to optionally enable<BR>2PL in jdbm (for
those #2 situations), and that we are willing
to invest<BR>the time in developing the extra
structure to support that, then I think<BR>we
can put this to rest. Even if we don't
do the actual development, I<BR>want to make
sure that we don't make any decisions that
would preclude<BR>it's introduction in the
future.<BR><BR>Please let me know your thoughts!<BR><BR>Cheers!<BR><BR>-
K<BR><BR><BR><BR> <BR> >
Kevin,<BR><BR>Postgres is a 2PL + MVCC combination.<BR><BR>I
am also having trouble seeing how MVCC adds
anything.<BR><BR>-bryan<BR><BR>-----Original
Message-----<BR>From: <A href="mailto:jdbm-developer-admin@...
color=#0000ff><mailto:jdbm-developer-admin@...
href="mailto:jdbm-developer-admin@...
color=#0000ff>jdbm-developer-admin@...:
JDBM Developer listserv<BR>Sent: 3/1/2006
10:36 PM<BR>Subject: re[4]: [Jdbm-developer]
Optimistic CC<BR><BR>Bryan-<BR><BR>Correct
- the 2PL (rw) + MVCC(ww) approach that you
are proposing is<BR>most certainly not optimistic.<BR><BR>The
MVCC approach that PostreSQL and others are
using (where all<BR>concurrency control is
being achieved via MVCC and there is no 2PL)<BR>definitely
has optimistic characteristics. With
MVCC there are no rw<BR>conflicts - ever.
That leaves only ww conflicts.<BR><BR>I
think I'm going on need some help from you
in understanding the<BR>combined 2PL/MVCC
approach. Can you please give me an
explicit<BR>transaction trace example of
how that would work? All of the<BR>transaction
flows that I can come up with wind up with
the read locks<BR>under 2PL preventing any
write contention at all... Given that
MVCC is<BR>primarily centered around preventing
rw contention, how exactly do you<BR>intend
to have MVCC to protect against ww conflict?<BR><BR>Thanks!<BR><BR>-
K<BR><BR> > Kevin,<BR><BR>Absolutely
right: _optimistic_.<BR><BR>CC gets divided
into three realms:<BR><BR>- locking<BR>-
timestamp<BR>- verification (aka optimistic)
<BR><BR>The notion in optimistic is that
you verify that the transactions did<BR>not
conflict. The proposed 2PL(rw) + MVCC(ww)
approach is NOT<BR>optimistic<BR>in this
sense since it uses locking to place an ordering
over read-write<BR>conflicts.<BR><BR>-bryan<BR><BR>-----Original
Message-----<BR>From: <A
href="mailto:jdbm-developer-admin@...
color=#0000ff><mailto:jdbm-developer-admin@...
href="mailto:jdbm-developer-admin@...
color=#0000ff><mailto:jdbm-developer-admin@...
href="mailto:jdbm-developer-admin@...
color=#0000ff><mailto:jdbm-developer-admin@...
href="mailto:jdbm-developer-admin@...
color=#0000ff>jdbm-developer-admin@...:
JDBM Developer listserv<BR>Sent: 2/28/2006
7:06 PM<BR>Subject: re[2]: [Jdbm-developer]
Opportunistic CC<BR><BR>Bryan-<BR><BR>Just
to clarify, I think you are refering to "optimistic"
not<BR>"opportunistic"... the papers
referenced refer to the former, not the<BR>later.
Opportunistic locking is something
used in net-bios and other<BR>distributed
file systems and it gives me the willies
- I've had no end<BR>of problems with opp
locks over the years.<BR><BR>I believe that
optimistic CC and MVCC are in the same genre
of CC<BR>algorithms (or at least MVCC can
be said to be relatively 'optimistic'),<BR>but
MVCC removes a large category of conflicts
that could cause an<BR>opportunistic algorithm
to force an abort (r-w, w-r). In MVCC,
the only<BR>conflict that can cause an abort
is a write-write conflict. The<BR>decision
of when and which tx to abort can be deferred
to commit time to<BR>increase the available
information for making a decision of which<BR>aborted
txs will require the least re-work. The
other school of thought<BR>is that an abort
should occur as soon as a w-w conflict is
detected...<BR><BR>I'm not sure that either
option is better than the other - they'll
both<BR>probably perform equally poorly for
a highly contested resource.<BR><BR>- K<BR><BR><BR> >
All,<BR><BR>I know that we have been discussing
things in terms of 2PL and MVCC,<BR>but I
think that it might be worth while to do
a little bit of reading<BR>on the third family
of concurrency control techniques: opportunistic.<BR>For
some examples, see [1], [2], [3]. I
have not read up in this area<BR>since I
was focusing on MVCC. However it does
appear likely that an<BR>opportunistic concurrency
control strategy could have the highest<BR>concurrency
for many scenarios.<BR><BR>FYI - I am prototyping
2PL with multiple granularities per Gray
and<BR>the JPEG that I distributed last week.<BR><BR>-bryan<BR><BR>[1]
<A href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff><http://en.wikipedia.org/wiki/Optimistic_concurrency_control></FONT></A><BR><A
href="http://en.wikipedia.org/wiki/Optimistic_concurrency_control"><FONT
color=#0000ff>http://en.wikipedia.org/wiki/Optimistic_concurrency_control</FONT></A><BR><BR>[2]
Bernstein, P. A. and Goodman, N. 1981. Concurrency
Control in<BR>Distributed Database Systems.
ACM Comput. Surv. 13, 2 (Jun. 1981),<BR>185-221.
DOI= <A href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff><http://doi.acm.org/10.1145/356842.356846></FONT></A><BR><A
href="http://doi.acm.org/10.1145/356842.356846"><FONT
color=#0000ff>http://doi.acm.org/10.1145/356842.356846</FONT></A><BR><BR><BR><BR><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>><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>><BR><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>><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>Contr><BR><BR><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>><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>C><BR><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>C><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>ontr<BR>ol.pdf<BR><BR>[3]
Apologizing Versus Asking Permission: Optimistic
Concurrency<BR>Control for Abstract Data
Types MAURICE HERLIHY Carnegie Mellon<BR>University.<BR> <A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff><http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf></FONT></A><BR><A
href="http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf"><FONT
color=#0000ff>http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf</FONT></A><BR><BR> "An
optimistic concurrency control technique
is one that<BR> allows transactions
to execute without synchronization,<BR> relying
on commit-time validation to ensure serializability."<BR><BR>-bryan<BR><BR><<BR> <BR>-------------------------------------------------------
This SF.Net<BR>email is sponsored by xPML,
a groundbreaking scripting language that<BR>extends
applications into web and mobile media. Attend
the live webcast<BR>and join the prime developer
group breaking into this new coding<BR>territory!<BR><BR><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164"><FONT
color=#0000ff><http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164</FONT></A><BR>><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164"><FONT
color=#0000ff><http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164</FONT></A><BR>2><BR><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164"><FONT
color=#0000ff><http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164</FONT></A><BR>2><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</FONT></A><BR>_______________________________________________
Jdbm-developer mailing<BR>list <A
href="mailto:Jdbm-developer@...
color=#0000ff><mailto:Jdbm-developer@...
href="mailto:Jdbm-developer@...
color=#0000ff><mailto:Jdbm-developer@...
href="mailto:Jdbm-developer@...
color=#0000ff><mailto:Jdbm-developer@...
href="mailto:Jdbm-developer@...
color=#0000ff>Jdbm-developer@...
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><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 xPML,
a groundbreaking scripting language that<BR>extends
applications into web and mobile media. Attend
the live webcast<BR>and join the prime developer
group breaking into this new coding<BR>territory!<BR><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164"><FONT
color=#0000ff><http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164</FONT></A><BR>2><BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</FONT></A><BR>_______________________________________________
Jdbm-developer mailing<BR>list <A href="mailto:Jdbm-developer@...
color=#0000ff><mailto:Jdbm-developer@...
href="mailto:Jdbm-developer@...
color=#0000ff>Jdbm-developer@...
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 xPML,
a groundbreaking scripting language that<BR>extends
applications into web and mobile media. Attend
the live webcast<BR>and join the prime developer
group breaking into this new coding<BR>territory!<BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</FONT></A><BR>_______________________________________________
Jdbm-developer mailing<BR>list <A href="mailto:Jdbm-developer@...
color=#0000ff>Jdbm-developer@...
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>
|