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

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