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

Yep! Very good analysis.

On Sat, Sep 10, 2011 at 4:15 AM, Ralph Johnson <[email protected]> wrote:

> On Fri, Sep 9, 2011 at 4:39 AM, Naveen Chawla <[email protected]>
> wrote:
> > > 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()"?
>
> I think that the phrase "transactions shouldn't carry direct
> references to the objects" means that the arguments to the transaction
> should not be direct references to the objects, but should be names of
> the objects.  Further, when the transaction gets serialized, it should
> not store a direct reference to the object but only the name of the
> object.  When the transaction executes, it will use the name to get a
> direct reference.
>
> This probably means that direct references are not stored in instance
> variables, though if the instance variable was treated as a transient
> and not serialized then it might be OK.   It is OK for local variables
> to hold references, unless you are referring to the local variables in
> a closure and then referring to the closure from an instance variable.
>  But that is just another way of saying "don't carry direct references
> to the objects", and only possible if your language has closures.
>
> I think the reason for the word "carry" is that transactions get
> serialized, i.e. they are permanent.  When you come back to a file
> that contains a bunch of transactions, and re-execute them, the
> transactions cannot refer to the objects directly, because the objects
> are in the database, or don't exist yet.  Business objects are not
> stored in the transaction log.  But since the transactions are
> serialized, we can move them from one computer to another and so
> migrate the database.  The transactions should not "carry" references
> to the objects, but only refer to their names.
>
> Names, of course, can be anything you want.  Strings, numbers, arrays
> of strings and numbers.  Anything that can be saved and restored
> easily.
>
> -Ralph Johnson
>
>
> ------------------------------------------------------------------------------
> Malware Security Report: Protecting Your Business, Customers, and the
> Bottom Line. Protect your business and customers by understanding the
> threat from malware and how it can impact your online business.
> http://www.accelacomm.com/jaw/sfnl/114/51427462/
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>

------------------------------------------------------------------------------
Malware Security Report: Protecting Your Business, Customers, and the 
Bottom Line. Protect your business and customers by understanding the 
threat from malware and how it can impact your online business. 
http://www.accelacomm.com/jaw/sfnl/114/51427462/

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