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]

Reply via email to