Subject | Re: [Firebird-Java] Connection Pool ?'s |
---|---|
Author | David Jencks |
Post date | 2002-12-02T00:52:27Z |
On 2002.12.01 19:10:58 -0500 William L. Thomson Jr. wrote:
assumed the connections would all time out eventually. It would be a good
idea, although not part of the standard DataSource contract.
having problems like this I almost always log each getConnection and
connection.close and study the logs.
Is all your usage like this?
Connetion c = ds.getConnection();
//log "I got a connection" + c
try {
//do something useful
}
finally
{
c.close();
//log "I closed a connection" + c
}
You absolutely need the finally block. I recommend always getting and
closing the connection in the same method to eliminate the possibility of
not calling the method that returns the connection.
tricky problems that way.
david jencks
> I am a little curious about how the connection pool logic works whenSorry, I don't remember if thee is such a method. I think I might have
> using FBWrappingDataSource.
>
> 1.) How do you close/destroy the pool when you are done? A method or
> something that would close all connections explicitly and politely, or
> is it not necessary?
assumed the connections would all time out eventually. It would be a good
idea, although not part of the standard DataSource contract.
>?? I think you have to measure performance in your situation to decide.
> 2.) How low can you set the time out without increasing server load
> during periods of low traffic? While not leaving connections open longer
> than necessary.
>The only way to return a connection to the pool it to close it. When I am
> 3.) How can you be sure a connection was returned. I know I could
> compare the max connections to the available one, but if for some reason
> the connection was not returned. What can I do to return it explicitly?
having problems like this I almost always log each getConnection and
connection.close and study the logs.
Is all your usage like this?
Connetion c = ds.getConnection();
//log "I got a connection" + c
try {
//do something useful
}
finally
{
c.close();
//log "I closed a connection" + c
}
You absolutely need the finally block. I recommend always getting and
closing the connection in the same method to eliminate the possibility of
not calling the method that returns the connection.
>Your connections are not being returned to the pool successfully.
> I will explain a little more on the second. If I understand the logic
> correctly setting the IdleTimeout/IdleTimeoutMinutes controls how long
> it takes to close a connection after connection close has been called.
> If no requests for a connection is made, the connection will time out
> and be closed. The time out will be used to close all connections down
> to the minimum setting of the pool.
>
> I believe once I set the IdleTimeout to low and it seemed as soon as
> connections were created they were destroyed. This only seemed to happen
> over a period that no requests for connections were made. Like over an
> hour or so.
>
> Now this was some time back and there may have been a problem in the
> driver causing this?
>
> Currently I have it set to 1 minute.
>
> However I seem to be having a problem with connections not being
> available. This seems strange since I am 99% sure close connection was
> called and succeeded. Yet it seems my connections are not being returned
> to the pool.
>
> I have double the amount of available connections and dropped the
> timeout down from 5 minutes to 1. After a while I get the following
> error.
>
> java.sql.SQLException: Problem getting connection:
> org.firebirdsql.jca.FBResourceException: No ManagedConnections
> Available!
>
> So why are my connections not timing out? I can wait over 5 minutes,
> while using a 1 minute timeout and still nothing.
>Again, I strongly recommend logging everything. I've found some really
> So I have a feeling my calling connection close is not registering with
> the pool or something?
>
> Under heavy loads this does not seem to be a problem. I mean I have two
> pools. The larger one that gets a hell of allot more request does not
> have available connection problems, at least not as quickly as the
> other.
>
> I would assume it to be visa versa. I would expect the larger pool being
> used more to run out sooner. Instead the smaller pool being used less
> seems to run out of available connections sooner.
>
> I hope this is not to vague. I can provide code if needed, but I am not
> doing anything special. Although things are not working the way I would
> expect.
>
> Help.
tricky problems that way.
david jencks
>
> --
> Sincerely,
> William L. Thomson Jr.
> Support Group
> Obsidian-Studios Inc.
> 439 Amber Way
> Petaluma, Ca. 94952
> Phone 707.766.9509
> Fax 707.766.8989
> http://www.obsidian-studios.com
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>