RE: [Jdbm-developer] DBCache discussion

[Thompson, B. B. <BRY...@sa...>]

Ok.  Let's get some references on the problem and do some more reading.

I believe that the design-now vs design-later question revolves around
whether or not their is, in fact, an interaction between the "segment"
API (treats the contents of the segment (pages) as untyped data, but
reserves some bits on each page for the DBCache header) and the record
API with record-level locking.

If these are isolatable, then DBCache can be implemented without regard
to the record locking strategy.  This seems to be the tread in recent
store architectures.

-bryan

-----Original Message-----
From: Alex Boisvert
To: Thompson, Bryan B.
Cc: Kevin Day; JDBM Developer listserv
Sent: 1/17/2006 2:00 PM
Subject: Re: [Jdbm-developer] DBCache discussion

Thompson, Bryan B. wrote:
> Overall my thinking on row/page/segment locking is that we need to get

> engaged in a new transaction
> engine, which will be of direct benefit.  With that in hand we can 
> consider row locking strategies.  I
> would rather duplicate DBCache first and then examine row locking
solutions.

My sentiment is that we should consider object-level locking (or 
versioning) head-first.   I anticipate it would be difficult and 
wasteful to retrofit a DBCache implementation with such concept because 
it necessitates a departure from page-level management where you don't 
have to think much about object relocation to a system where allocation 
and indexing concerns are fundamental to achieving high performance and 
high levels of concurrency.

alex