Re: ACIDity of Prevayler 2.6

Rick Ross <[email protected]> Wed, 14 Nov 2012 11:35:50 -0800
Newsgroups gmane.comp.java.prevayler
Message-ID <[email protected]>
I don't believe that to be true.   Atomicity means that no part of the transaction occurs if any part fails for any reason. 

That is most certainly not true of the example, or really of any thing in Prevayler that doesn't explicitly save old values and cram them back in on an error (unless you are tasting, which comes closer to true atomicity).  In databases, as in life, nothing is perfect.  But every precaution is taken to ensure data integrity.  In essence, the db log is copied, the transaction data is appended and then the log is moved back.  Only after that is complete is the transaction safely complete and the old log available for destruction.  Now, it is still remotely possible that power outage, OS fart or other strangeness could cause something to go wrong during this procedure, but this is a vanishingly small chance.

That doesn't mean Prevayler has to do it, but as I see it Prevayler is not really atomic in any way.   I think it could easily be and could support multiple level undo right out of the box with a slightly different strategy for managing it's own persisted transactions, but that is a different discussion.

R


On Nov 14, 2012, at 11:05 AM, Klaus Wuestefeld <[email protected]> wrote:

> Atomicity is not about detecting human errors in the coding that leads
> to the operations in a transaction. It is about cleanly surviving
> system crashes.
> 
> I would agree Prevayler provides less *Consistency* built in now, not
> lack of Atomicity. Consistency, yes, is something that makes sense
> from the point of view of a human being.
> 
> Even your best RDBMS with your typical constraints will not detect all
> possible buggy SQL(DML) statements sent to it. That doesnt invalidate
> its atomicity.
> 
> With the food taster we were consistent with regard to Java's strong
> typing + RTEs. Now we are consistent only with regard to Java's strong
> typing (which is already better than RDBMS constraints IMHO).
> 
> It was a conscious trade-off to become less consistent, on the one
> hand, but faster, more newb-friendly, simpler and use half the RAM, on
> the other.
> 
> It seems to be trivial to implement a Transaction base class that does
> food tasting internally, orthogonal to Prevayler, if one so wishes.
> 
> Klaus
> 
> ------------------------------------------------------------------------------
> 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


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