It's easy enough to find a reference
implementation of a B+Tree and re-implement it; as long as we've
thought through all the tradeoffs (I think Henrik made this point).
Speaking of which, I think the Right Thing is developing the B+Tree
library separately from Elephant, so others will be able to use it
and to achieve weak coupling.
Definitely! It's also one good place to split the work up among
several contributors so the whole project doesn't fall on one primary
developer!
The other approach to fine-grained locking is to use speculative
concurrency (roughly what Rucksack calls versioning). This means
that
we assume there are no conflicts, don't bother to lock anything,
copy-
on-writes and invalidate transactions at commit time that do have
conflicts (i.e. that read and operated on anything that was written).
I believe the canonical term for this is "Optimistic Concurrency
Control".
Quite right!
We should move this discussion to the wiki and start capturing
requirements, a basic decomposition, and some design decisions to make.
See:
http://trac.common-lisp.net/elephant/wiki/DesignTradeoffs
http://trac.common-lisp.net/elephant/wiki/LispDataStore
Ian
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
