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: [email protected]
>> 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: [email protected]
>> 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: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
