DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38026>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38026 ------- Additional Comments From [EMAIL PROTECTED] 2006-01-18 20:49 ------- The releaseXXX() methods are safe, but the getFactory() is not. It is possible that 2 threads calling the getFactory() method will receive different LogFactory instances for the same classloader. I'm not saying that you should make getFactory() synchronized, but you should say more explicitly in the javadoc that the getFactory() method not necessarely returns the same factory instance in a multithreaded environment. Consider the following simple scenario: No Factory has been created yet. 2 Different threads have just been started. Thread1 calls LogFactory.getFactory(). This method will look in the cache, but since it is the first time the factory is retrieved, the cache will return null and the thread will continue creating the factory instance. In the middle of the getFactory() method, thread1 is suspended and thread2 becomes active. Thread2 calls getFactory(). The cache still returns null! (Thread1 didn't put the factory instance in the cache yet). So thread2 will continue creating a new factory instance. Both threads will end up having their own instance of a LogFactory. One of them is cached, the other not. In most cases, this is no big deal: it's just an instance of a factory that has been created too much. This won't cause problems in > 99% of the applications. But it could get worse: if you now call LogFactory.releaseAll(), one instance of the factory won't be released at all (because it's not present in the cache)! If your factory implementation consumes a lot of resources, this could cause a serious negative impact on your system. regards, Maarten -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
