Re: New to Prevayler: "Baptism problem" basics?

That's brilliant, Klaus! So can I do as many
direct-field-access modifications, and on as many levels as I like, on my
"prevaylerSystem"-derived object, one-after-the-other, within a
single Transaction ("executeOn()"), or am I restricted to just one line of
change per transaction?
All the sub-objects must also implement Serializable, yes?

So this "baptism problem" isn't really a problem at all?! I'm surprised
not to have read "As long as your object's from "prevaylerSystem" you're
good to go" about how to avoid the "baptism problem".

Am I right that this only applies to making changes and not to queries? Even
so, do you recommend using "Query" for every access as a replacement for
all direct access? Does doing so de-necessitate any and all concurrency
control? If I had no concurrency control of my own, in what sorts of cases
would I be ok to use direct access instead of using Query?

By the way, Klaus, I cannot put into words how great I think you are.
On 9 September 2011 15:07, Klaus Wuestefeld <[email protected]> wrote:

> Yes.
>
>
> On Fri, Sep 9, 2011 at 10:59 AM, Naveen Chawla <[email protected]>
> wrote:
> > Ok so I'm not sure if I'm seeing the baptism problem correctly in your
> > example. It would seem obvious that you'd wanna access your object via
> > "prevaylerSys" (but your first "baptism problem" example doesn't do
> that).
> > So, is that all that's needed to avoid it??
> >
> > So would the following work, for example
> >
> > ((YourSys) prevaylerSys).users.get(userid).password=newPwd;
> > and all other types of field-access modifications too, as long as you get
> > your object via "prevaylerSystem"?
> > On 9 September 2011 13:44, DB <[email protected]> wrote:
> >>
> >> Hi, Naveen
> >>
> >> The principle is: what is within Prevayler's protection should never be
> >> accessed without this protection.
> >> I'll try to explain the baptism issue through an example:
> >> class ModificationWithBaptismProblem implements Transaction {
> >> private User user;
> >> private String newPwd;
> >> ModificationWithBaptismProblem(User u, String np) { user = u; newPwd =
> np;
> >> }
> >> void executeOn(prevalentSys) {
> >> u.setPwd(newPwd);
> >> }
> >> }
> >> class ModificationWithoutBaptismProblem implements Transaction {
> >> private int userid;
> >> private String newPwd;
> >> ModificationWithoutBaptismProblem(int id, String np) { userid = id;
> newPwd
> >> = np; }
> >> void executeOn(prevaylerSys) {
> >> ((YourSys) prevaylerSys).getUser(userid).setPwd(newPwd);
> >> }
> >> }
> >> the difference is that in the former the transaction will hold a
> reference
> >> to an object that is out of Prevayler's protection ('cause it comes from
> the
> >> application through the constructor).
> >> Prevayler cannot assure that the referenced object will be the same when
> >> executing the transaction recoverying process.
> >> I'd say that your prevalent system (that comes as a param to
> executeOn())
> >> is the entry point for your business objects and you should access them
> only
> >> through it (within transactions).
> >> Hope it helps.
> >> Dear friends, please, correct me if I'm wrong. Any additional comments
> >> would be appreciated :D.
> >> Best regards,
> >> DB
> >>
> >>
> >> On Fri, Sep 9, 2011 at 6:39 AM, Naveen Chawla <[email protected]>
> >> wrote:
> >>>
> >>> I really couldn't understand the term "remove the code that references
> >>> business objects directly inside Transactions". I thought the very
> first
> >>> line of the Transaction itself was
> >>> ((MyObjectType)prevalentSystem).doSomething()? Isn't this referencing
> the
> >>> business object directly to call the method in the first place? If I
> did
> >>> MyObjectType m = (MyObjectType)prevalentSystem; , I could still use "m"
> >>> thereafter, right? Am I ok as long as I call methods from "m" and not
> >>> references? Or is it a different rule?
> >>>
> >>> Can my ".doSomething()" method itself reference and play around with
> the
> >>> objects in "m" without restrictions?
> >>>
> >>> I'm lost maybe because the code examples on codehaus are gone:
> >>> http://docs.codehaus.org/display/PREVAYLER/The+Baptism+Problem . And
> also
> >>> because I couldn't understand the phrase "transactions shouldn't carry
> >>> direct
> >>> references to the objects". Does this only mean as instance variables
> of
> >>> the Transaction, or also within local variables inside "executeOn()"?
> >>>
> >>> Can I get the simplest possible example with the problem vs without,
> and
> >>> the best practices for easily and flexibly modifying objects
> top-to-bottom
> >>> without ever having to worry about the baptism problem?
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Why Cloud-Based Security and Archiving Make Sense
> >>> Osterman Research conducted this study that outlines how and why cloud
> >>> computing security and archiving is rapidly being adopted across the IT
> >>> space for its ease of implementation, lower cost, and increased
> >>> reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> >>> _______________________________________________
> >>> To unsubscribe go to the end of this page:
> >>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> >>> _______________________________________________
> >>> "Databases in Memoriam" -- http://www.prevayler.org
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Why Cloud-Based Security and Archiving Make Sense
> >> Osterman Research conducted this study that outlines how and why cloud
> >> computing security and archiving is rapidly being adopted across the IT
> >> space for its ease of implementation, lower cost, and increased
> >> reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> >> _______________________________________________
> >> To unsubscribe go to the end of this page:
> >> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> >> _______________________________________________
> >> "Databases in Memoriam" -- http://www.prevayler.org
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Why Cloud-Based Security and Archiving Make Sense
> > Osterman Research conducted this study that outlines how and why cloud
> > computing security and archiving is rapidly being adopted across the IT
> > space for its ease of implementation, lower cost, and increased
> > reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> > _______________________________________________
> > To unsubscribe go to the end of this page:
> > http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> > _______________________________________________
> > "Databases in Memoriam" -- http://www.prevayler.org
> >
> >
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org