On Thu, 2005-12-01 at 10:22 -0600, Curt Arnold wrote: > > I have suggested targeting Java 5 in log4j 2.0. However, I plan on > experimenting with substantially reducing the scope of locks in > log4j > 2.0 instead of just incrementally using new locking features with > the > current approach.
Again, I just want to second Curt's thought. There's nothing terribly mystical about the locks that Java 5 versus what Log4j 1.3 uses. If you can reduce the amount of locking (thereby increasing concurrency) then you are likely more performance than switching lock implementations. [As a note, given the amount of existing breakage 1.3 contains, I'm wondering if the deadlock fix I proposed would be reasonable. 99% of the users may not even know, even those that extend from the Appender classes.] One approach that needs to change to reduce locking, is to reduce object reuse. For multi-threaded applications, it's better to create new objects than attempt to reuse existing objects and increase your locking potential. Please take a look at this: http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
