In this model, the Persistence Layer doesn't help you with ACID
properties. This works if you assume that Domain Object Layer is the
ONLY thing that can touch the database. From an organization point of
view, the Manager is the central point of contact for a collection of
objects (like accounts), and nobody is allowed to permanently
manipulate
an account except via operations defined on the Manager. The Manager
can therefore be responsible for concurrency control.
Concurrency at the domain object level could be done via
versioning/journaling as in Rucksack, or via locks. I have never used
the former, but it sounds like a great idea.
I hadn't realized that you were relying on the Manager to lock
objects, and that only one can be used at a time when 'checked out'.
This does sound exciting. I guess however that Rucksack offers two
quite different things: A pre-exising Btree implementation, and an
in-memory versioning concurrency control model. I assume that you are
mentioning these together because the Rucksack Btree by itself would
not
give us an ACID transaction model, as we currently have with the other
backends.
That is correct. The data store is responsible for ensuring, within a
transaction body, all of the ACID properties for any access to
persistent objects (unless you are using caching, see prior e-mail).
Ian
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
