Re: Making transaction calls act like a Java method call would

At the risk of sounding really stupid, I presumed the baptism problem meant
anywhere you modify your prevalent object outside of the first arg of
transactions. There is just as much risk of doing this outside of
transactions as inside, if not more. The deserialize-then-execute behaviour
handles cases only inside transactions, while also not allowing changes
made to non-prevalent objects passed in to be reflected in the app. That's
what I was referring to when I was talking about an app-wide
baptism-problem checking/fixing mode while not sacrificing anything else.

On Friday, 4 November 2011, Klaus Wuestefeld ?<[email protected]> wrote:
>> what about the baptism problem
>> Outside transactions?
>
> What do you mean?

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