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]