----- Original Message -----
From: "Paul Speed" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 11:30 PM
Subject: Re: Tomcat: Distributed Session Management revisited
>
>
> Tom Drake wrote:
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom
Drake"
> > <[EMAIL PROTECTED]>
> > Sent: Tuesday, November 13, 2001 1:25 PM
> > Subject: Re: Tomcat: Distributed Session Management revisited
> >
> > ... stuff deleted ...
> >
> > | > | It would be possible to do this for the HttpSession methods
> > | > | themselves (the container would know what's going on), but what do
you
> > do
> > | > | about session attributes?
> > | > |
> > | > | HttpSession session = request.getSession();
> > | > | MyObject mo = (MyObject) session.getAttribute("foo");
> > | > | mo.setName("bar");
> > | >
> > | > I believe that, in this case, it is incumbent upon the application
to
> > call
> > | >
> > | > session.setAttribute("foo", mo);
> > | >
> > |
> > | This violates the principle that the application programming model
should
> > | not change, but it's certainly feasible to say "if you want load
balancing
> > | to work on this container, you have to call HttpSession.setAttribute()
> > | whenever you modify an attribute's properties".
> > |
> > | By itself, though, this doesn't provide any support for locking
against
> > | simultaneous updates (i.e. what you do in "synchronized" blocks in a
> > | single VM).
> > |
> > | It's a little funny funny ... by the time we invent API to solve all
these
> > | problems, you've just defined a pretty fair chunk of the functionality
of
> > | EJBs ...
> > |
> >
> > Locking issues aside, this presents a fair problem for the servlet
> > container. How to know if any session attribute was modified per
> > your example.
>
> I'm not saying this is necessarily a "good" idea, but you can byte
> compare the resulting session serialization to see if the session
> objects have changed. All you have to do is keep a local copy of
> the original session during the request. Not very pretty, but
> is a solution that wasn't discussed.
>
> I tend to agree with Costin that the session API isn't well suited
> for failover/distribution. I don't think it's impossible though.
> Plus, if you decide to develop an API separate from the session...
> it really starts to look like EJB.
I completely agree, that the API lacks proactive support for things in the
background that may fail.
But given the fact, that we support a reference implementation which has
managed to provide really professional services to users (other ref
implementations are just for demonstration, nobody would use them in
production) and there are (commercial) solutions, that provide session
fail-over in the limitations of this API, we **must** try to provide a
solution. The API does not specify, how often the container may try to
provide that service or what means it utilizes to do that. Nothing is 100%
and I think it is better to live with the uncertaincy we discuss here than
with the more likely problem that an instance fails and there is no
potential replacement.
Byte-comparison is not the worst solution. If we think about differential
updates, byte comparison is a good candiate for that and surplus one that
promises good performance.
If the user wants to place things in a session that she does not need to be
replicated, she has the option to declare them transient and write a getter
that checks if the Attribute is present, otherwise reconstructs it (in the
case of a picture, reloads it from disk). The user has the choice to design
for performance or ease. We only need to document the options.
Mikaaaa
:wq
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
