Re: Food Tasting, Memory and Rolling Back Transactions.

On Mon, Jul 27, 2009 at 2:13 PM, Klaus
Wuestefeld<[email protected]> wrote:

> These two things you wrote below seem sort of contradictory:
>
> > 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
> ...
> > 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.

How so?

Note that I'm talking about slightly different concepts in these two
paragraphs: The first uses the term "fail" while the second uses the
term "bug". A transaction can fail (throw a RuntimeException) without
it being a bug.

If the issue is my emphasis of "*same* Transaction", what I meant was
that there are plenty of bugs in the wild where an inconsistency is
introduced which only leads to visible errors at some later time. The
food taster can only help if an error becomes visible (causes a
RuntimeException) during the same Transaction that caused it.

Cheers,
Justin

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org