Re: ACIDity of Prevayler 2.6
"Justin T. Sampson" <[email protected]> Wed, 5 Dec 2012 18:38:36 -0800
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAAshuuEEABjF=HpDMPsWbyFLvFdTZ2-A-ciK8+VXjH0=SCpT6g@mail.gmail.com> |
(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]> 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