To get this thread restarted in the right direction, I thought it'd be
good to recap a little from your posts so far...

> I have set the max active connections to 40.
> My active connections keep increasing, they never seem to return back
> to the pool,
> eventhough when no-one is visiting the site.
> (Well, I have had up to 3 idle connections and that is the most I have
> ever had)
>
> After a few days, the active connections reach to 37, and then
> afterwards the active connections
> are reset to 0.
>
> It basically starts from 0 to 37 and then again 0 to 37, and so on....
> 3. An idle connection can only be idle for an X amount of time and then
>    it will be removed from the pool and get destroyed
>
> 4. An idle connection will become an active connection when it is 
>    required and then returned back to the pool as an idle connection
>   when calling connection.close()
To comment on #3, there is nothing to force destroy a connection at a
set age.  It's good until a test of the connection fails and then it's
closed.  That's what the validationQuery is for.  On that note, it's be
good to add validationQuery="select 1" to your <Resource ... />
definition so connections are tested before they get loaned out. 
That'll prevent problems at the 8 hour mark for MySQL db connections.

To comment on #4, I would also expect that which is why it's interesting
you see the behavior you do.  It's also interesting you see the pool
fill even when idle which implies *something* is grabbing a connection
and not necessarily closing it properly.  Might be time to run a
profiler on it and see exactly where pool connections are getting
borrowed and returned.

--David

sinoea kaabi wrote:
> This question about static variables seems a bit deeper than I 
> thought, the more I think about it the more confused I get.
>
> I could accept the fact that we should create new objects of Dao's,
> but for getting a datasource or connection it should make sense
> to have a utility class with static methods.
>
> Collection<Branch> branches = new BranchDao().loadBranches(
> new DBUtil().getDataSource(),  // This feels crap, I'd rather use 
> DBUtil.getDataSource() (without new)
> 1);
>
>
> DBUtil should have static methods for retrieving a datasource or a connection,
> creating a new DBUtil for each request does not feel right.
>
> Well, you say that static methods don't necessarliy improve performance
> in the long run, but why does the code at the bottom work for others.
>
>
> And what is a thread-safe object:
> An object whose state cannot be modified
>
> So is a connection a thread-safe object or not?
> It looks like you can modify its state (closing and opening it)
>
> Below is a new connection object created, it is therefore 
> not a static class variable, only the method is static.
> This means that the method should be thread safe, since a new connection
> object is created for each thread.
>
>
>
> public static Connection getConnection(){
>
>     try {
>
>         Context context =(Context) new 
> InitialContext().lookup("java:comp/env");
>
>         DataSource dataSource = (DataSource) context.lookup("jdbc/FooBar");
>
>         Connection connection = dataSource.getConnection();
>
>         return connection;
>
>     } catch (NamingException namingException) {
>
>         log.fatal(namingException);
>
>         throw new RuntimeException(namingException);
>
>     } catch (SQLException sqlException) {
>
>         log.fatal(sqlException);
>
>         throw new RuntimeException(sqlException);
>
>     }
>
> }
>
>
>
>
>
>   
>> Date: Wed, 17 Sep 2008 09:40:16 -0400
>> From: [EMAIL PROTECTED]
>> To: users@tomcat.apache.org
>> 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.
>>     
>>> 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.
>>     
>>> 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.
>>     
>>> 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., ...
>>
>> --David
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>     
>
> _________________________________________________________________
> Discover Bird's Eye View now with Multimap from Live Search
> http://clk.atdmt.com/UKM/go/111354026/direct/01/
>   


---------------------------------------------------------------------
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