> You stated that the new storage manager will do over-writing, and that
> the MVCC-needed tuples will be kept somewhere else and removed when not
> needed.  
> 
> It is possible to use SDB, and keep the MVCC-needed tuples somewhere
> else, also in SDB, so we don't have to add MVCC into the SDB existing
> code, we just need to use SDB to implement MVCC.

Possible, in theory.

> The issue was that SDB does two-phase locking, and I was asking if MVCC
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Due to this fact seems we'll have to change SDB anyway. With MVCC per-tuple
locking is not needed. Short-term per-buffer _latches_ are used to prevent
concurrent changes in a buffer, no locks made via lock manager.
I'm not sure does SDB API allow _any_ access to modified tuples or not.
I would rather assume that it doesn't.

> could be layered on top of SDB, rather than being added into SDB.

As I said - possible, in theory, - and also not good thing to do, in theory.
MVCC and 2PL are quite different approaches to problem of concurrency
control. So, how good is layering one approach over another, who knows?

Vadim

Tue, 16 May 2000 11:51:19 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Berkeley DB license
At 11:51 AM 5/16/00 -0700, Mikheev, Vadim wrote:

> > The issue was that SDB does two-phase locking, and I was asking if MVCC
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Due to this fact seems we'll have to change SDB anyway. With MVCC per-tuple
> locking is not needed. Short-term per-buffer _latches_ are used to prevent
> concurrent changes in a buffer, no locks made via lock manager.

The locking, logging, and buffer management interfaces are all available
independently.  Certainly it would be possible to modify the current
implementation to do System R-style shadow paging, or some other technique,
but to continue to use the current log manager to roll back or reapply
changes as necessary.

In that case, you'd take out the current 2PL lock acquisition calls during
a transaction, and add code to create shadow pages for updates.

Certainly the interfaces are there.  It'd be interesting to us if users
could select 2PL or MV for concurrency control on initialization, and
it appears on the face of it that that should be possible.

> I'm not sure does SDB API allow _any_ access to modified tuples or not.
> I would rather assume that it doesn't.

At present, Berkeley DB provides only 2PL.  We don't permit dirty reads,
but that's an implementation detail that would be fairly simple to change.
Berkeley DB does page-level, not record-level, locking.  There are short-
term mutex locks that protect shared structures.

My bet is that it would be better to use the lock manager, rather than
(say) spinlocks, to protect pages during updates; it's possible during
multi-page updates, like btree page splits.  Since the updating thread
may be descheduled during relatively long operations, you'd rather not
be holding a spinlock.  And you can acquire and release locks via lock
manager calls without trouble.

> MVCC and 2PL are quite different approaches to problem of concurrency
> control.

I'm joining the discussion quite late.  Can you summarize for me the
thinking behind adopting MVCC in place of 2PL?  Have you got performance
numbers for the two?

					mike


Tue, 16 May 2000 14:14:13 -0700
"Michael A. Olson" <mao@sleepycat.com>
RE: Berkeley DB license