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

In prevalent systems, everything that you execute is 're-executed'(later) in
a restore process.

If your transaction carry business objects reference, in the re-execution
process this will be a different object than the original.

That's why you have to get your business objects from the prevalent system..

Let me try show you with some pseudo-code..

bank_new() {
    Account account = new Account(this._next_pk);
    return account;
}

bank_deposit(Account account, int amount) {
    account.deposit(amount);
}

and correct one:

bank_deposit(int account_id, int amount) {
    account = get_from_reporisoty(account_id); #((YourSys)
prevaylerSys).users.get(userid)
    account.deposit(amount);
}

If your execution is:

acc = bank_new()
prevalent.system.deposit(acc, 100);

In the restore process, will be registered that you executed
'prevalent.system.deposit(acc, 100)' and java serializer will cretate
another Account instance to restore this transaction.. (since it receives a
Account object)

In the correct code, *always*, account objects come from some collection
inside your prevalent system, so on the restore process, it will get this
account object from this prevalent system and this object is the one that
you really want, not some "copy".


And that's why Clock class exists too.. because in a restore process
"system.time" will be different than the original time, while clocks holds
the correct timestamp than your original timestamp transaction..

Hope it helps.. and sorry for the english :)




2011/9/9 Klaus Wuestefeld <[email protected]>

> 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