Re: Making transaction calls act like a Java method call would
Naveen Chawla <[email protected]>
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAGs7EcWe8JjdPOhS6irjY6nfc=Op_5b3iwYYKUOv0FAyKEWfZw@mail.gmail.com> |
Great point Klaus. If only it could isolate the baptism-problem without preventing other things. And what about the baptism problem outside transactions? I'd prefer direct transactions by default but offering an application-wide baptism-problem-debug mode, which notifies, fails and/or corrects inconsistencies after each transaction, to check for ANY occurrence of the baptism problem inside or outside transactions. I don't mind having to to override "equals()" on my prevalent class especially for using just this debugging mode. After activating the mode, after each transaction, it compares the object to the would-be prevalent version. If there's a mismatch, it prints to the console, throws an Exception, and/or fixes either the original object or the prevalent version if I choose it to (and desirably, but not essentially, even log the corrections as transactions, so it's 100% baptism-problem-proof). Then if and when I'm happy I've eliminated any such inconsistencies, I disable the mode if I want normal performance. This way I could get application-wide baptism-safety without sacrificing anything else. On 3 November 2011 17:39, Klaus Wuestefeld <[email protected]> wrote: > Hi Naveen, > > Prevayler deserializes your transaction, even the first time it is > executed, so that the baptism problem will fail fast, ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org