> 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]
