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>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: [logging] Log4JLogger thread safety issue
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <1137622693.5323.57.camel@knossos.elmet>
References: <1137622693.5323.57.camel@knossos.elmet>
Content-Type: text/plain
Date: Thu, 19 Jan 2006 17:17:40 +1300
Message-Id: <1137644260.4690.16.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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