Hi Edwin,

> was wondering how hard/easy it is to implement MVCC in picolisp's DB.
> has anyone attempted/thought about this?

You mean a multiversion concurrency control, with the key feature that
instead of changing objects, new objects are created as copies of the
old ones?

Speaking of myself, I haven't attempted it. I could imagine that it can
be done by defining specialized relation daemon classes, which take care
of the necessary bookkeeping.

I suspect, however, that it would have quite a performance penalty,
because the object caches lose their advantages, and also because a lot
more writing to the DB files will be triggered. Just imagine, for
example, that if a B-Tree node is changed, it may cause the creation of
a complete new path of tree nodes.

What advantages do you have in mind?

> in this line of thought, is there a doc that describes the file layout
> of picolisp's database? that is, aside from the source.

The key descriptions are in "doc64/structures".

1. How external symbols are encoded in the DB: There are notes in line
   66, "Symbol tail" / "External", concerning the flag encoding of
   external symbol names, and in line 81 the "Name final short" /
   "Externals" for encoding of external symbol names.

2. The layout of the database file: Line 281 through 304 about the
   layout of the block record structures.

Then, the assignment of entity classes and b-trees to the individual
files is controlled with the '*Dbs' global (normally set with the 'dbs'
function. There is an example in "http://doc/refD.html#dbs";, taken from
the demo in "app/", which shows how these data are assigned to twelve
database files.

For example, the third line

   (1 +Item +Ord)                               # (3 . 128)

means that objects of the classes +Item and +Ord are created
in the third database file, with a block size of 128 bytes.

The ninth line

   (4 (+Item nr sup pr))                        # (9 . 1024)

means that the B-Trees for number, supplier and price of items reside in
the ninth file, with a block size of 1 kB.

I hope this gives at least some hint to get started. Please ask
if the details are not clear.

- Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to