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.
-Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
