Re: ACIDity of Prevayler 2.6
Karl Wettin <[email protected]> Thu, 6 Dec 2012 21:10:15 +0100
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <[email protected]> |
Personally I enjoy the idea of a transaction that is aware of all the changes it did to the root, rolling back the delta on abort. It could be made truly modular so it in no way taints the core. A sort of POJO-delta-thingy that could be applied to all sorts of applications. The simplest solution I can think of is a bit of reflection glue that access setters with something like ReflectiveDeltaTransaction.this.set(root, "users[identity].name, "foo bar"). A more complex solution would be a decorated/instrumented root passed down to the transaction, returning instrumented instances of everything accessed from it, allowing for automatically keeping track of all access to setters in order to create a delta. The latter would even be backwards compatible with existing code by either decorating all
transactions when executed (read: tainting the core) or by making transactions extend RollbackableInstrumentedRootTransaction.
But if you ask me then all this is to spend a lot of writing code for no good reason. I doubt that many people who use Prevalyer care about, or are indeed ever in need of rolling back. To be frank, if you're not comfortable with your own code then perhaps you're in the wrong business or should consider spending most of your time writing unit tests.
Actually I think this discussion is a bit out of scope for this thread, i.e. is Prevayler 2.6 ACIDic? And does it matter if it is? My answer to both those questions, as you all might know by now, is no.
Please don't misunderstand, I've rewrote this mail several times trying not make it sound derogatory. I'm afraid it still has that smell to it. In fact I welcome all ideas that might solve rollbacks. Yours was a good and new one that I need to spend some time thinking about.
karl
On Dec 6, 2012, at 7:14 PM, Arnaud Masson wrote:
> 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
------------------------------------------------------------------------------
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