Re: Food Tasting, Memory and Rolling Back Transactions.

Ok.   I am following, and I am on board.  I will probably kill my  
taster too.

I will do everything possible to ensure that no changes to the object  
model are made until I have assured myself that all preconditions are  
met.  So my code should never throw an exception out of the  
transaction *after* changes have begun.

So inside my executes, it would look something like this :

         // check everything
         .....

         // Do changes
         .....

So yes, I am ok with keeping the model safe from deterministic  
errors.  My concern is an error beyond my control after the model has  
been modified in the transaction.   As I understand it Prevayler will  
not set the model back to the state it was in before the transaction  
started.  I can't imagine how it could.    And now reading this I  
understand that this is independent of food tasting.  Of course, the  
transaction will not be serialized to disk so I can reload the model  
to the correct state.  Since we are in an exception state I would be  
unlikely to be able to reverse the changes made to the model anyway,  
so a reload is really required in all cases.

Unless I've made a mistake above, I think I am good to go.   Thanks  
for taking the time to drive the points home.

R




On Jul 27, 2009, at 12:41 PM, Justin T. Sampson wrote:

> 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
>


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