tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Date Thu, 08 Sep 2005 15:51:41 GMT
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=36541>.
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=36541





------- Additional Comments From rick@knowleses.org  2005-09-08 17:51 -------
(In reply to comment #43)

> When would anyone want to use a "threadUnsafe" session set/getAttribute?
> As we have seen, NOT syncing this causes hangs - so therefore developer
> needs to do this (if he uses these methods). Wouldn't it make more sense to
> just sync it further down in tomcat, as suggested here, rather than needing
> to sync the whole method every single time you use this in your code?

One possible case is for a really simple dumb cache: where you expect the 
result to be present in the session on every time except the first (eg where 
the read:write ratio is 10000:1). In such a case, if the get is 
unsynchronized, it's safe to say:

        Object cached = session.get(key);
        if (cached == null) {
            synchronized (session) {
                cached = session.get(key);
                if (cached == null) {
                    cached = "blah";
                    session.put(key, cached);
                }
            }
        }

I understand there is potential waste doing two gets (one in and one out of 
synchronized block), but this only gets executed on the first hit, so 
decreases in significance as the read:write ratio goes up. 

Anyway - that's one case I've found where an un-threadsafe get helps 
performance wise, especially on lower spec machines short on memory (only 
through subjective observations though - don't have any numbers).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message