Re: ACIDity of Prevayler 2.6

Using immutable structures from the functional-programming world can 
help to have correctness without to actually implement rollbacks
   model = transaction.execute(model)
where model is an instance of an immutable class.

The cost is probably more memory usage (but usually that doesn't require 
full deep-cloning if you use the optimal functional data structure).

And of course it makes queries more safe since the model can never be 
changed
     result = query.execute(model) // model cannot be changed

Also it fixes the latency issue of concurrent tx/queries
because while the  new model is written on disk (after tx),
you can still use the old one for pending concurrent queries.

writeLock.lock()
try {
    M newModel = transaction.execute(this.modelAtomicRef.get())
journal.write(transaction); // queries can still run on the old model 
during IO
    this.modelAtomicRef.set(newModel);
}
finally {
     // no need to rollback anything
     writelock.unlock();
}

Typically the old and the new models would share many immutable sub-graphs.


  On 05/12/2012 18:38, Justin T. Sampson wrote:
>
> (I'm writing this without wifi, so apologies if it eventually shows up 
> out of order with later messages.)
>
> Thanks for continuing to bring clarity to the conversation. I think 
> it's an important topic. I'm really pretty zealous about correctness 
> myself. So here's my perspective.
>
> For one thing, I think it's worth noting that databases, even with 
> rollback capability, are typically run at something lower than true 
> "serializable" transaction isolation. Many don't even claim to support 
> serializability, and some claim to but fall short, such as Oracle 
> (implementing "snapshot" isolation instead). The fact that Prevayler 
> implements true, unequivocally serializable semantics has always been 
> one of my favorite features, which is why I bristle at the suggestion 
> that it might fall short. (While this is perhaps technically a matter 
> of isolation rather than atomicity, the properties do overlap as we've 
> noted.)
>
> I do think it's a fine idea to support rollback somehow; as I've 
> mentioned before, I even think the food taster is a nice example of 
> what's possible in the prevalent model, though something dealing with 
> editing the journal or adding rollback markers is probably a better 
> approach.
>
> I just don't _personally_ see rollback as a very big deal. I've 
> noticed over the years that I worry about different things than many 
> Prevayler critics do (you're not a critic, of course). We see 
> criticism of keeping all data in memory, or of not having a query 
> language, or of not having rollbacks... Which to me are all kind of 
> the point of Prevayler. Features, not bugs.
>
> The things I worry about, on the other hand, are true correctness 
> issues: There's no guarantee that queries won't modify data, and 
> there's no guarantee that transactions will be deterministic. Those 
> are the big issues to me. The other things are minor inconveniences, 
> or not problems at all. It's always flabbergasted me that people worry 
> so much about those little issues while happily accepting these bigger 
> issues.
>
> On Dec 5, 2012 8:03 AM, "Karl Wettin" <[email protected] 
> <mailto:[email protected]>> wrote:
>
>
>     4 dec 2012 kl. 18:06 skrev Klaus Wuestefeld:
>
>>>     Sadly, that product did not make it to market and a portion of the
>>>     reason was that the decision makers were not comfortable with
>>>     an entirely new data system that did not have the same level of
>>>     commitment to data protection that RDBMSs claim.
>>
>>     Were they happy and confident with Prevayler with the FoodTaster
>>     (rollback on exceptions)?
>
>     This discussion has wandered quite a bit from the original can of
>     worms I opened up.
>
>     I sent the original mail in this thread because I think it's a
>     horrid idea to claim Prevayler is something it might not be.  I'm
>     pretty sure that a thread with 50+ mails in a few days on a list
>     that normally yield a handful per year is strong evidence for us
>     having at least controversy on our hands.
>
>     Let me sum up what I think me and a few others tried to say:
>     We will not give the ACID stamp of approval to a persistency layer
>     that lacks possibility to rollback a half baked transaction that
>     managed to execute some changes to the persistent data. This is
>     according to us the very definition of all-or-nothing.
>
>
>     I'm afraid that I still don't understand what the arguments of
>     those that do not share the opinion that rollback is required.  Is
>     it simply that you state rollback is not a required feature for
>     ACIDity? Or perhaps that rollback is not a required feature of
>     ACID in Prevayler due to a transaction in Prevayler is something
>     quite different than a transaction in other systems? Or is it
>     something completely different? Could someone please try to sum it
>     up for me in a sentence or two?
>
>     While re-reading the complete thread I noticed that almost all the
>     posts are hung up on the food taster. In my opening post I didn't
>     mean to say that the food taster was the solution, all I ment to
>     say is that the food taster indeed supplied built in rollback
>     functionality and now there is no such built in feature. If
>     rollback is required now then it must be manually written by the
>     person that implements the transaction. Several
>      hypothetical alternative solutions for rollback out of the box
>     has been presented in this thread, but as I've written in all my
>     previous posts I don't give a rat's ass wether or not  Prevayler
>     does rollbacks out of the box,  pass the test for ACIDity or what
>     not since it works great as is. I've never had any problems even
>     though I've been running some rather large implementations with
>     heavy user load and millions of transactions per day.
>
>     I just think it's a horrid idea to claim Prevayler is something it
>     might not be.
>
>
>     karl
>
>     ------------------------------------------------------------------------------
>     LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>     Remotely access PCs and mobile devices and provide instant support
>     Improve your efficiency, and focus on delivering more value-add
>     services
>     Discover what IT Professionals Know. Rescue delivers
>     http://p.sf.net/sfu/logmein_12329d2d
>     _______________________________________________
>     To unsubscribe go to the end of this page:
>     http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>     _______________________________________________
>     "Databases in Memoriam" -- http://www.prevayler.org
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
> _______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org