Let's not get testy here -- your post had a lot of errors in it, including your concept of static methods and how they are handled in a threaded environment. This whole discussion is getting very off topic. I'll drop this thread here and respond to the OP on a thread that's still on topic.
--David Johnny Kewl wrote: > > ----- Original Message ----- From: "David Smith" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <users@tomcat.apache.org> > Sent: Wednesday, September 17, 2008 3:40 PM > Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections > keep increasing.... > > >> Comments inline ... >> >> Johnny Kewl wrote: >>> >>>> >> So, what exactly does it mean when we say that Tomcat is thread >>>> safe >> for >>>> >> requests. >>>> >> Tomcat creates a new thread for each request, so somehow my static >>>> >> methods >>>> >> are then thread safe (incdirectly, since it is managed by Tomcat). >>> >>> I actually searched all over to try find something for you.... this >>> looks ok >>> http://www.codestyle.org/java/servlets/faq-Threads.shtml >>> >>> >>> But here my un-scientific way of thinking about it... >>> >>> When tomcat sends a thread into your doGet method... >>> All those local variables in that thread are ok... >> As long as you mean variables defined inside of the doGet() method. >> Class instance variables are not cool in servlets. >>> >>> So I think about it as each thread being a lane on a big >>> freeway/highway... >> But objects are not thread local unless they are setup that way >> implementing something like ThreadLocal. Only the references to the >> object are local. > > No... ouch mention 2 words in a sentence and association kicks in.... > ha ha > I'm saying... > These local variables are completely private; there is no way for one > thread to access the local variables of another thread. > Nothing at all to do with ThreadLocal... > >>> >>> So yes you right in a way... Tomcat isnt allowing those local method >>> variables to get mixed up... >>> but the second you decalare a static method or static variable... you >>> had better be sure its thread safe. >> Let's not confuse static methods and static variables. Static variables >> should be avoided unless they are true constants. Static methods on the >> other hand are fine, but need to be careful when those static methods >> interact with object instances that may not be thread safe. > > All true... but damn hard to see when you plugged into someone elses > engine... > ... in your own code in a static method, only have to worry about your > globals... > But someone elses code... not easy... unless they explicitly say > thread safe. > > >>> What happens to that highway is that all the lanes merge into one, and >>> every car has to go through it... >> Now your are talking about a singleton -- a whole different ball of wax. > > No... I'm not... its actually your C analogy > >>> When you add synchronized... your 30 lane high way becomes a single >>> lane and its one car at a time... >> Still in singleton land with the one lane analogy. Syncs do add a huge >> performance penalty though, so even outside of singletons, syncs should >> be avoided as much as possible. >>> >>> You dont want to add synchronized because here you have the TC guys >>> gone thru all the hassle of making sure you can have a 30 lane >>> highway... and you bang it into one lane.... so new is better because >>> each lane gets its own engine... and java is pretty damn good at >>> garbage collecting, that little bit of memory is a blip on the radar >>> screen... >>> >>> You got to really know what your code is doing when its static... you >>> got to know its thread safe, and it can be really hard to see that 30 >>> car pile up coming on the highway ;) >>> >>> My way of thinking about this stuff..... mad science - chapter 1 ;) >> Johnny -- You might find the java language reference an interesting >> read. It describes all the rules regarding threading, access, value vs >> reference variables, etc., ... > > Maybe you want to tell us why it is his code is leaking connections? > What is it exactly in his code thats jumping a connection? > Do you know? > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]