----- 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.
Perhaps we don't need to.
Perhaps our mechanism could configured to be either pessimistic
or optimistic about whether a web-app always tells the session
if an attribute has changed.
If configured to be pessimistic, TC could simply assume that an attribute
may have changed, and therefore must always send the entire
session object to another server. Of course, this would result in more
network traffic and possibly reduced performance.
If configured to be optimistic, TC could assume that unless
session.setAttribute, or session.removeAttribute were called, no
changes were made to the session, therefore, no data transfer
would be required at the end of the request (aside from a 'releaseLock'
message). Otherwise, only the 'changed' or 'deleted' attributes need
to be sent to another server. This would probably result in a significant
reduction in network traffic, and improved performance.
This way, we could say, that any web-application will work with the
expected semantics, but if you want to improve your performance,
make sure that your web-app calls setAttribute any time an attribute
value changes, and make a one-line change to server.xml that changes
the tomcats behavior (to be 'optimistic').
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
