Re: ACIDity of Prevayler 2.6

Klaus, Justin, I understand your arguments, and agree that we are talking about violating consistency, not atomicity, but I think you are missing an important point....

On Nov 14, 2012, at 10:22 PM, Justin T. Sampson wrote:

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

And what about those unexpected exceptions? At that point, the system is running, but in an inconsistent state. They very fact that those exceptions are unexpected means you can't check them with pre-conditions.

Divide all errors and exceptions into 3 classes:

1) Those caused by outside influences - power fail, OOM, etc. Assuming these are fixed, replaying the journal will not now re-create those errors. Consistency is maintained.
2) Expected exceptions thrown by the transaction. Since they are expected, a correct transaction will have made no inconsistent changes to the system. So even thought they *will* be thrown again on replay, consistency is not violated.
3) Unexpected exceptions thrown by the transaction. Now, the system is in an inconsistent state. It is running, but inconsistent. What else can you do but shut it down, and fix the problem? Restarting won't help, because the exception will again be thrown, and the system will again be inconsistent. Yes, the problem is a bug, but it has made the system unusable past that point.

I submit that to have that behavior in a production system is unacceptable. To have a system that is so sensitive to unexpected problems that all you can do is shut it down and fix the problem is unacceptable.

You would need teams that reliably produce perfect-zero (not near zero :-) bugs for that to be practical.

We are building a system that uses prevayler, and have found that practically, we need something like rollback to deal with this. And, I'd be happy to have the above reasoning refuted......

-pb

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

-pb

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