Re: ACIDity of Prevayler 2.6

On Wed, Nov 14, 2012 at 6:51 PM, Klaus Wuestefeld <[email protected]> wrote:

> If not atomicity, what shall we call that property Prevayler has, on
> system crash and recovery, of producing all the effects (even bugs) of
> the last transaction it received or none of the effects?


We should call it atomicity. :)

Atomicity is not about rollbacks. Rollbacks are a distinct feature that a
persistence layer may or may not provide.

Atomicity means that if a transaction makes multiple changes to the data,
either all of those changes are persisted or none of them are. And this is
one of the most essential properties of Prevayler, coming directly from the
"command" pattern for transactions.

If a transaction makes a change and then throws an exception, it has simply
made a change and thrown an exception. It has not made additional changes,
so atomicity is not in question. Consistency at the business logic level
may be in question, if the exception was unexpected and the changes made
before the exception violate some business rules. If the exception was
expected, business logic shouldn't be violated.

When using Prevayler myself, I never used the food taster, and would
typically write transactions in the form (a) check preconditions, (b) throw
exception if preconditions are violated, (c) continue with whatever the
transaction is supposed to do. Throwing an exception doesn't mean the
transaction "failed"; it correctly checked the preconditions and threw an
exception as designed. The food taster, rolling back on any exception,
would make this style very expensive.

Indeed, I'd suggest that good coding should mean that objects in general
don't let themselves get into inconsistent states. Anything else is a bug.
Do bugs happen? Sure. The food taster protects (inefficiently) against one
narrow class of bugs: Those that result in business logic inconsistency AND
throw exceptions. If you find that to be a very common class of bugs for
you, the food taster (or other rollback implementation) may be appropriate.
I've generally found that bugs that result in business logic inconsistency
but do NOT throw exceptions are at least as common, as are (with defensive
coding) bugs that DO throw exceptions but do NOT result in business logic
inconsistency.

I typically only used Prevayler with small XP teams producing near-zero
bugs anyway... :) If you have a larger or less-disciplined team,
nondeterministic bugs (which DO affect atomicity) would worry me more than
consistency bugs.

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

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