commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] Log4JLogger thread safety issue
Date Thu, 19 Jan 2006 04:17:40 GMT
On Wed, 2006-01-18 at 22:18 +0000, robert burrell donkin wrote:
> on the subject of thread safety, there is a potential issue with
> Log4JLogger - take a look at getLogger(). i'd like a second opinion (and
> a third and a forth, if possible) so i'll post this now before i analyse
> it.
> 
> (see
> http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200511.mbox/%3cDDDD97FE8191FA4DA8DF33EC938394630157E1F5@MSSAHQ11.corp.valero.com%3e)
> 

I don't think this is valid. Yes there is a race condition but it's
harmless.

=== Scenario begins ===

A Log instance "log" is deserialized

Thread A calls log.info("infomsg"). There's no log object so one is
fetched from log4j; object X is returned.

Thread B calls log.warn("warnmsg"). There's no log object so one is
fetched from log4j; object X is returned again.

One of A or B updates the Log4JLogger.logger member to point to X. The
other then stomps over this value - with a reference to exactly the same
object.

A and B then call the info and warn methods on object X. Because X is
thread-safe, this works fine.

=== Scenario ends ===

I can't see any problem here....

NB: the synchronized keyword also ensures that CPU caches are correctly
synchronized. However even taking this into account I can't see a
situation where anything bad can happen.


Regards,

Simon



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


Mime
View raw message