DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30028>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30028

session attributes Map may become inconsistent start causing "strange" problems





------- Additional Comments From [EMAIL PROTECTED]  2004-07-11 23:44 -------
Remy,

<quote>

SRV.7.7.1 Threading Issues

Multiple servlets executing request threads may have active access to a single
session object at the same time. The Developer has the responsibility for
synchronizing access to session resources as appropriate.

</quote>

I wouldnt say this implies that HttpSession is not guaranteed to be thread-safe
and to be fair it is quite ambiguous about either. As to my interpretation the
spec is talking about objects that are stored in session. And it would be
logical because the container cannot possibly synchronize access to them.

The session itself is a different matter altogether. It is a container resource
and I dont think it would qualify as a "session resource" the spec is going on
about. I would say that the container have to synchronize calls to
setAttribute/removeAttribute to ensure session consistency.

Performance difference between HashMap and the synchronized map is negligible
and the advantages are obvious. Basically unless session is accessed by the
single servlet implementing SingleThreadModel there is no way to gurantee
session connsistency? Even <jsp:useBean> does not synchronize against the
session. So everyone is a winner if StandardSession.attributes is synchronized?

I do hope that what i said here makes sense because Tomcat is one of the few
servers that doesnt care about setAttribute/removeAttribute thread safety, which
is a shame.

Regards,
Vlad

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to