POS

[BRIAN SPILSBURY]

> BS> Also _just_ having a transactional POS kills persistence of
> BS> execution entirely, which is something definately worth
> BS> considering.
> 
> Would you explain?  Assuming that the stack and registers are part of
> the begin/end commit cycles, what breaks?  What is the alternative?

Ok, you _can_ use a transaction database for persistence of execution
but only if _everything_ is in the transactional database. Including
your stack, registers, etc, and anything that you might now or at 
some future time deal with directly, or indirectly with that thread.

This basically means _everything_. Now I don't know about you, but 
transactional updates on my stack are likely to be at least several
orders of magnitude slower, and if everything is in a transactional
db, then that's also fine, since you won't have to think about using
it, so it will also be a transparent solution.

The alternative is pretty much the same thing, only with a much much
larger grain, ie at the system level, rather than the object level.

Looking at how cheap disk space is becoming, its not unreasonable
to copy-on-write blocks if they've been clean since the last system commit.

Then we can roll back to the last checkpoint by using these
'originally clean' blocks. Here a transaction is a 'commit-system'
call. We can recover to a non-commited state however, if we can handle
a (hopefully small) level of disjointness in data. Most applications 
probably don't care terribly much if things are slightly out of whack
especially in an oop system (delete mailbox letter10) what? it's already
gone? That's good enough for me.

You will want to be able to ensure that a solid, expensive, transactional
database can be supported, I'd have wrappers to alter the default memory
allocation, then implement the db at a system level, copying objects on
insertion, with the copy beign in synch allocation space.

(defmethod insert ((this magic-db) that)
  (actually-insert this (allocate-synchronous (deep-copy that))))

or something along those lines.

There are probably problems with this, please don't hesitate to
point them out. :)

Brian