On Jul 26, 2006, at 9:12 PM, Peter Wilkinson wrote:

>
> On 27/07/2006, at 11:01 AM, David Binger wrote:
>
>> This is the basic motivation
>> behind MVCC, which Durus does not currently provide.  I think we
>> will provide MVCC in Durus 4.0.
>
> Hi David,
> This reminds me of something I've been meaning to ask... Is there a
> public roadmap or just a list of possible additions that you see
> going into future versions of Durus (and QP).

There is no written roadmap, public or private.
Our general intent with these packages is to continue to keep them
stable and useful in our applications.

There is one idea in the air, though, for Durus, and I'll go ahead
and describe it here, since I already hinted at it.

The FileStorage2 format includes an offset index when it is packed.
A FileStorage2 instance starts by reading this entire index into memory
for fast access.  This is fine as long as you can afford those startup
seconds and as long as you have enough RAM to hold the entire index.

I'm interested in introducing a FileStorage3 format that is like
FileStorage2 except that the packed offset index would be written
in a form that would make it possible to use (for reading) directly
from the file, instead of loading it all into RAM.  This will make
startup times much faster and the storage server will use much less
RAM.  It will only maintain an in-memory offset index for instances
whose offsets have actually changed since the last pack.

This change opens the door for a new type of client/server behavior,
in the common situation where clients can have direct access to the
underlying file.  In particular, this new type of client could maintain
an independent offset index, and do all reads directly, without
interacting with the server at all.  The server would handle all
writes, and it would distribute offsets with invalidations, so that the
index of each client would always reflect a consistent view of the
database.  Every client would need to be notified when the storage
file was
packed so that the local offset index could be reset.  The result
of this should be that clients see a consistent, though possibly
not-quite-current view of the database as they are reading, and
conflicts, if necessary, are handled when and if there is a commit.
(That's what I'm thinking is MVCC.
Please correct me if I am wrong about that.)
Clients would require more memory, as they would need to maintain
the offset index of all new objects, but the server would use less
memory,
and it would not be bothered by delivering object records.

That's it for the future.  We also have a list of improvements
that are already coming in Durus 3.5, which I hope we can release
next month.  The 3.5 changes will make make the server work better
with Unix Domain Sockets.  We're adding support for allocating
oids in blocks, and for bulk-loading object records, among other
things.