Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 38026]  - [logging] LogFactory is not thread-safe
In-Reply-To: <bug-38026-7685@http.issues.apache.org/bugzilla/>
Message-Id: <20060118041825.783B4E1@ajax.apache.org>
Date: Wed, 18 Jan 2006 05:18:25 +0100 (CET)

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=38026>.
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=38026


------- Additional Comments From skitching@apache.org  2006-01-18 05:18 -------
I don't believe this issue is valid. The Hashtable javadoc specifies that this
class is internally synchronized (ie already thread-safe) which will prevent
race conditions between concurrent calls to get/put.

There is potentially an issue with the removeAll method, as a
ConcurrentModificationException could occur if one thread is in removeAll while
another is adding an entry to the table. However removeAll should only ever be
called by the container during container shutdown so this is not expected to
ever be possible in practice.

Adding synchronisation everywhere just to avoid a theoretical conflict with
removeAll isn't a good idea; that's a significant performance hit.

If I've got this wrong, please let me know. Otherwise I will close this issue in
a couple of days.

-- 
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org