Hi, Endre... Thank you for your answer... I have noted that for a single request, the server use a single thread (as you said), but for different requests on the same session, the server could use different threads...
But the solution you wrote is quite useful... I think... I'll try something like this. Anyway, I've tried another solution, not so elegant... Using an attribute for a Logger subclass, for saving a context, and a Layout subclass for printing it... Not so good... Thanks again! --- Endre Stølsvik <[EMAIL PROTECTED]> escribió: > 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] > > ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
