Re: Food Tasting, Memory and Rolling Back Transactions.

On Sat, Jul 25, 2009 at 10:30 PM, Ross Rick <[email protected]> wrote:

> On Jul 25, 2009, at 5:02 PM, William Pietri wrote:
>
> > > 3.   If I turn it off, what are the ramifications?    It seems
> > > possible that rolling back a transaction would then be my
> > > responibility.   Is that correct?
> >
> > The risk is that a transaction blows up in the middle, leaving your
> > model in an inconsistent state, one that might not be what you'd get
> > from replaying the log. I think of that less as being responsible for
> > rolling back, and more for being responsible that your transactions
> > never, ever break. But perhaps it amounts to the same thing.
>
> I am perfectly fine with testing everything I can before executing the
> transaction. My issue would be with the things that are somewhat out
> of my control, like say, memory allocation.   I suppose in that
> situation I would have to force the user to quit anyway, and only be
> losing the last transaction, but I'm not so sure that's gonna work.

You guys have actually described three very different issues, only one
of which the food taster helps with. (By the way, you may notice that
Prevayler purists like me are fairly anti-food-taster!)

1. Remember that all of Prevayler, including the food taster, assumes
that your code is deterministic. Even if a RuntimeException is thrown,
Prevayler assumes that it was thrown deterministically. The exception
is propagated on up to the client code, and Prevayler goes right on
executing further transactions.

If you have a transaction that fails nondeterministically, it could
just as well succeed when run against the food taster and then fail
against the king, or fail later when replayed from the journal. It's
the nondeterminism that causes the inconsistency, not the exception.

Conversely, if a transaction fails deterministically, it will always
fail, whether against the food taster, against the king, or later when
replayed from the journal. Therefore, eliminating the food taster does
not introduce any particular inconsistency: Whatever state the system
is in after the exception is thrown, that state will be faithfully
reproduced when replaying the journal, because the same exception will
be thrown (and ignored, at that point).

2. Note that Prevayler does treat Errors specially. Basically, Errors
(such as OutOfMemoryError) are assumed to be nondeterministic. If an
Error is thrown while executing a transaction, Prevayler will refuse
to process any further transactions and queries, to prevent an
inconsistent state from being observed. (Any memory held by Prevayler
will be released at that point.)

The only way to recover is to restart, or at least close that
Prevayler instance and create a new one. The failed transaction will
be replayed along with the rest of the journal.

Of course, the food taster doesn't prevent that situation, and
actually exacerbates it by using twice as much memory. :)

3. I concur with William's point that the goal is really correctness,
and rollback is just one tool to help achieve correctness -- as long
as you understand its limits.

Ideally, each object should maintain its own internal consistency even
when a RuntimeException is thrown. In fact, I think a major reason to
throw a RuntimeException is precisely to maintain consistency: If you
try to add a DOM Document as a child of a DOM Element, it's not going
to add the Document as a child and *then* throw a DOMException to
*indicate* that the Element is now in an invalid state, it's going to
throw a DOMException right away to *prevent* putting the Element into
an invalid state.

A rollback mechanism such as the food taster only helps you defend
against a very narrow class of bugs: *Deterministic* bugs that put the
system in an *inconsistent state* AND cause a RuntimeException to be
thrown from the *same* Transaction that introduced the inconsistent
state. Any other bug will slip by unnoticed. (This is not unique to
Prevayler!)

Cheers,
Justin

------------------------------------------------------------------------------
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org