Re: [jbosscache-dev] Caching log.isTraceEnabled() as instance variable
By the way, with the email below, I'm assuming that there's a least a
few of the CommandInterceptor instances that are created at runtime and
the same instance is used throughout all cache lifespan.
I dunno whether any of this CommandInterceptor instances are created on
a per invocation basis. If they are, they can safely cache
log.isTraceEnabled() as the duration of the CommandInterceptor instance
is short. I doubt this is the case though.
Cheers,
Galder Zamarreno wrote:
Hi all,
Yesterday while looking at the JBC code, I spotted that
CommandInterceptor caches log.isTraceEnabled() as instance variable and
that pretty much all classes extending this use it.
In a standalone world, where JBC runs on its own this is fine. However,
when running within AS, log4j settings could change at runtime
(conf/jboss-log4j.xml is hot deployable) and therefore, someone could
enable TRACE logging for org.jboss.cache at runtime which wouldn't have
any effect with the current JBC code.
As far as I can remember, it's generally recommended not to cache things
like this in code running within AS. Then again, I can see how
convenient caching such value is rather than calling
log.isTraceEnabled() all the time. I doubt using an instance variable or
calling log.isTraceEnabled() would have a real impact performance wise
when TRACE is not enabled.
Thinking about this, I wonder whether any callback(s) could be
implemented when the log4j settings are updated after a hot deployment
and within this callback, update interceptors' trace settings...
Thoughts?
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat