Of course a *copy* of the reference is passed to a method call. 

I'll go crawl back into my hole.

Sri

> -----Original Message-----
> From: Steven Porter [mailto:[EMAIL PROTECTED] 
> Sent: Friday, April 08, 2005 1:04 PM
> To: Tapestry users
> Subject: RE: Clustering mutable objects
> 
> > It should be noted that the session stores the reference 
> and not the 
> > value.
> 
> Java passes references by value.  This is where your 
> misunderstanding arises.
> 
> You should take a look at some articles on how Java passes references:
> 
> http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
> 
> The assignment in your point 4 below does not change the 
> value stored in the http session because the address in 
> memory of the string "Mary" was stored, not the address in 
> memory of the variable "name".
> 
> Cheers
> Steve
> 
> >
> > Say  we have a cluster with two nodes: node-A and node-B.  Now 
> > consider the following timeline:
> >
> > 1. Application on node-A executes
> >
> >   String name = "Mary";
> >
> > 2. Application on node-A executes
> >
> >   session.setAttribute("username", name);
> >
> > 3. App-server on node-A notices this change to the session and
> >   a) serializes the value corresponding to "username"
> >   b) broadcasts to all nodes in the cluster.
> >   Now node-B believes the value of the session attribute 
> "username" to 
> > be "Mary"
> >
> > 4. Application on node-A executes
> >
> >   name = "John"
> >
> > 5. Application on node-A executes
> >
> >   String foo = (String)session.getAttribute("username");
> >
> >   The value of foo is "John".
> >
> > 6. Application on node-B executes
> >
> >   String bar = (String)session.getAttribute("username");
> >
> >   The value of bar is "Mary".
> >
> > Sri
> >
> > > -----Original Message-----
> > > From: Yu, Ed [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, April 08, 2005 11:35 AM
> > > To: 'Tapestry users'
> > > Subject: RE: Clustering mutable objects
> > >
> > > You are replacing the session attribute in the case of 
> String, but 
> > > in the other case, you are modifying the attribute of the object 
> > > which is stored within the session.
> > >
> > > -----Original Message-----
> > > From: Sri Sankaran [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, April 08, 2005 10:32 AM
> > > To: Tapestry users
> > > Subject: RE: Clustering mutable objects
> > >
> > > I recognize the immutability of Strings.  My question is 
> how is it 
> > > immune the problem.  I see the same stale value problem 
> possible if 
> > > I do
> > >
> > > String name = "Mary";
> > > session.setAttribute("username", name); name = "John";
> > >
> > > Sri
> > >
> > > > -----Original Message-----
> > > > From: Shing Hing Man [mailto:[EMAIL PROTECTED]
> > > > Sent: Friday, April 08, 2005 10:59 AM
> > > > To: Tapestry users
> > > > Subject: Re: Clustering mutable objects
> > > >
> > > > Java.lang.String is immutable - it has no setter method.
> > > >
> > > > Shing.
> > > >
> > > >
> > > > --- Sri Sankaran <[EMAIL PROTECTED]> wrote:
> > > > > I was reading Tapestry In Action and did not understand the 
> > > > > implication of clustering a mutable object. Hope you 
> can explain.
> > > > >
> > > > > To set the stage, the section states that an app server --
> > > > such as Web
> > > > > Logic -- broadcasts a change to all servers in a cluster in
> > > > response
> > > > > to an invocation of the setAttribute method of an
> > > HttpSession.  The
> > > > > article goes on differentiate mutable and immutable objects
> > > > placed in
> > > > > a session.
> > > > > It says that depending on the sequence of the steps, the
> > > value of a
> > > > > session attribute on server in a cluster can be stale.
> > > For example:
> > > > >
> > > > > session.setAttribute("some token", x);
> > > x.setSomeValue("some value");
> > > > >
> > > > > In this case, since the object referred to by 'x' is
> > > being modified
> > > > > *after* a call to setAttribute, it may not get 
> propagated to all 
> > > > > servers in a cluster.
> > > > > The cagey *may not* is because we may get lucky if the app 
> > > > > server hasn't got around to serializing 'x'
> > > > > and broadcasting it, before the application invokes the
> > > > setSomeValue
> > > > > method.
> > > > >
> > > > > My question is: How is this any different if x were 
> an immutable 
> > > > > object -- such as a String?  Wouldn't we have the 
> same problem?
> > > > >
> > > > > Sri
> > > > >
> > > >
> > > > Home page :
> > > >   http://uk.geocities.com/matmsh/index.html
> > > >
> > > > Send instant messages to your online friends 
> > > > http://uk.messenger.yahoo.com
> > > >
> > > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail: 
> > > > [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > 
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: 
> > > [EMAIL PROTECTED]
> > > For additional commands, e-mail: 
> > > [EMAIL PROTECTED]
> > >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: 
> [EMAIL PROTECTED]
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to