Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 36541]  -
    session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Message-Id: <20050908125929.6445F132@ajax.apache.org>
Date: Thu,  8 Sep 2005 14:59:29 +0200 (CEST)

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 remm@apache.org  2005-09-08 14:59 -------
(In reply to comment #33)
> > Overall, it means it's not
> > portable, and the webapp really should plan on syncing on the session externally
> > wherever needed.
> If you use different techniques this might become pain.
> It might be hard to tell everyone to synchronize against session, and in the end
> you have the same as synchronize in the base class. Well not really the same as
> tomcat can synchronize against the map, we have to synchronize on a wider
> context - the session.

You indeed have to sync on a wider context in many cases.

> > What I am willing to provide (this is the intent of the code in
> > 5.5.x right now), by default, is making sure the HashMap cannot get corrupted,
> > and that the infinite loop described in this report cannot occur.
> I wonder how this can be done?
> You might have to introduce your own map implementation, no?

No, because at this point I believe making sure that the HashMap does not get
corrupted (using syncs on put and remove) is enough to guarantee that the get
method doesn't enter an infinite loop (by returning null, or the result when
there's a problem - it will be unpredictable, but seems to me equivalent to the
higher level concurrency issues if you mix and match reads/writes in the webapp
for critical data without being careful).

Other than this, it doesn't look that the collection being used with its default
parameters is that optimal.

> Is it possible to create a thread-safe hash-map without synchronization?
> Ok, if two threads put in an element with the same key it might not be
> deterministic which of both are really set then, but this is not the problem we
> have to solve.

Maybe using a fully array based structure rather than a linked list would make
it more robust (ie, reads could be bad, writes could be lost, but the structure
would remain consistent). There is stuff like ConcurrentHashMap, but it of
course does synchronization of its own.

I did agree previously (hence the current code in the 5.5 branch) that
robustness is good, and that the HashMap structure should be protected, as
there's no way to restore it, so there are syncs for put and remove.

Since there's a real demand and you guys are quite persistent, I now agree on
adding an extra configuration parameter on the context allowing to define the
sweet spot for the collection size, as well as its synchronization policy (the
default being the current 5.5 behavior, unless/until it is shown to still be
able to cause the inifinite loop originally described in the report).


-- 
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