It should be noted that the session stores the reference and not the value.
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]
