On Thu, 16 Feb 2006, Raul Carazo wrote: | Maybe there is an answer to my question but... If so, | please, refer me to it. | | Both NDC and MDC works on a thread, so if you create | another logger in another thread, you'll noy see the | value you had set before... | | Some servers, like Weblogic, uses several threads, so | it's possible that you don't take the same thread in | your web Session.
Where do they use several threads? You are guaranteed that in the same method-invocation, e.g. doPost(), obviously just one thread will do the run. If however you go outside that thread, by invoking some other resource, or using some worker-pool, you're obviously out of luck on that approach. I guess you'll basically have to send along some context-object that enable you to bind back to the original requestor. | | I'd like to set a value (id of the person in session) | for a HttpSession, not a thread. IS it possible??? I do something along the lines of this: I have a super-servlet that implements the service() method, fetches the httpsession, fetches the id, shoves it into the NDC, going into a try-finally block, doing super.service (or call some "specialService()" method instead), and in the finally block, i do NDC.remoce(). Note the -remove- call. It shouldn't have been necessary (.clear() should have been sufficient), but the NDC as it stands has implemented this in a very strange, inefficient and bad way: instead of using a ThreadLocal, they use "their own" synchronized-hitting threadlocal implementation. If you don't call remove, _your application_ will never be fully freed from the thread, and you can utterly forget reloading in e.g. tomcat. That added to the fact that this implementation is very costly compared to the real ThreadLocal: synching. _However_, the new java threadlocal (from java 1.3) have another problem: it very often cause stale data in servlet containers that recycle their threads when reloading an application (as they all do), and you're back at the beginning. However, this is not as bad as forgetting to do .remove() on the current log4j impl, as that will -keep the thread object- around forever. If you don't like psycho memory leaks; check out, and vote for, this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531 Some background for that bug: http://www.jroller.com/page/tackline?entry=fixing_threadlocal Basically: an object of a class from the webapp which is held in a threadlocal, will hold a reference to its class, which holds a reference to its classloader, which again holds a reference to all classes loaded by that loader, which means that all statics in all those classes will be "reachable gc-roots", which means that all objects they point to will be held. If such a static is a ThreadLocal (which is often the way threadlocals are used), you're screwed: the Thread will end up holding your entire web application inside one or several entries in its threadlocal map, and won't ever let go. Regards Endre. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
