In principle, I agree with Craig's give "the user enough rope to hang herself with",
but in this case I think it's a mistake. I think too many people will assume
sessions are thread-safe when they're not. Threading is not an easy problem and
testing and debugging it is a nightmare.
The performance hit will be minor. The extra synchronization is in the noise, and
essentially all requests to JSP pages are serial wrt sessions. Obviously, Craig is
right that static pages should not synchronize session, but static pages don't
participate in a session, i.e. <%@ page session=false %>.
For example, Rod McChesney's example is not thread safe:
> For instance, read-only beans that initialize themselves at once when the session
is
> created would never need synchronized access.
How does the bean determine if the session has started? session.isNew may not work,
because another page might have started the session. The only way I can think of is
to test and set a session variable, and that requires synchronization. jsp:useBean
has to do the same thing. (see below)
And the login example for the processRequest thread should synchronize the
processRequest method. Did everyone implementing that example synchronize it?
Or Ben Engber's question:
> It seems that what people are saying is that javax.servlet.http.HttpSession is not
thread-safe,
> which I assumed it was.
The "thread safety" of HttpSession is close to worthless because it synchronizes the
wrong object. The 'getValue' make be atomic, but a 'getValue' followed by a
'putValue' is no longer thread-safe.
jsp:useBean, for example, uses 3 synchronization calls. Without the extra
synchronization, two simultaneous requests could get null from the session and both
could initialize the new bean. (For this case, the internal synchronization of
getValue and putValue are pure wasted overhead.)
<jsp:useBean id='foo' class='Bar' scope='session'/>
Bar foo;
synchronized (session) {
foo = (Bar) session.getValue("foo");
if (foo == null) {
foo = new Bar();
session.putValue("foo", foo);
}
}
Scott Ferguson
Caucho Technology
Hans Bergsten wrote:
> "Craig R. McClanahan" wrote:
> > [...]
> > Synchronization of application level data objects is an application level
> > issue, not a server problem. Servlets and JSP pages operate in a multithreaded
> > server environment. The principles about what and when to synchronize are easy
> > to learn and apply, and should not be built in to the server that doesn't know
> > which of your objects needs protection and which do not.
> >
> > Askling that the server to "protect you from yourself" by serializing requests
> > to the same session is like buying a steak knife but covering up most of the
> > blade with rubber -- you can still (slowly) cut the meat, but you're not so
> > much at risk for cutting your finger. For myself, I'd rather learn to use the
> > knife safely so I can take advantage of its abilities.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
