> 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
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
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.