[jbosscache-dev] Caching log.isTraceEnabled() as instance variable

[Galder Zamarreno]

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