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. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
