Subject | Re: [Firebird-Java] FBManagedConnection |
---|---|
Author | Rick Fincher |
Post date | 2002-09-27T15:40:09Z |
Hi Stefan,
One thing you have to do with pooling is be sure to close all statements and
result sets on a connection. In a non-pooling environment closing a
connection closes all result sets and statements. If you close a connection
in a pooling environment the connection is not actually closed but returned
to the pool, so open statements and results sets survive.
This will eat up all the available connections. To keep it from tying up
your entire system you can set the number of open connections to a non-zero
number. That way only Firebird will run out of resources rather than your
system.
The real fix is to go through your code and find all instances of closing a
connection and add the code to explicitly close the statements and result
sets used by the connection before closing the connection itself.
Hope this helps,
Rick
One thing you have to do with pooling is be sure to close all statements and
result sets on a connection. In a non-pooling environment closing a
connection closes all result sets and statements. If you close a connection
in a pooling environment the connection is not actually closed but returned
to the pool, so open statements and results sets survive.
This will eat up all the available connections. To keep it from tying up
your entire system you can set the number of open connections to a non-zero
number. That way only Firebird will run out of resources rather than your
system.
The real fix is to go through your code and find all instances of closing a
connection and add the code to explicitly close the statements and result
sets used by the connection before closing the connection itself.
Hope this helps,
Rick
----- Original Message -----
From: "Stefan Mühlemann" <smue@...>
To: <Firebird-Java@yahoogroups.com>
Sent: Friday, September 27, 2002 1:02 AM
Subject: [Firebird-Java] FBManagedConnection
> Hello,
>
> i had the problem, when i used built in pooling and had no active
> connection, after idletimeout was gone the connection was not returned
> properly to firebird.
> FBWrappingDataSource returned connection and created a new one because
> minSize of pooling was 1.
> But the connection was not returned to firebird. So after a while it
> ended up eating all my resources of firebird (many, many open
> connections).
>
> The code i think is the problem (from FBManagedConnection.destroy()):
> if (currentDbHandle != null) {
> try {
> // if (log!=null) log.debug("in
> ManagedConnection.destroy",new Exception());
> mcf.releaseDbHandle(currentDbHandle, cri);
> }
> catch (GDSException ge) {
> System.out.println(getClass().getName() + " / Can't
> detach from db: " + ge.toString());
> throw new ResourceException("Can't detach from db: " +
> ge.toString());
> }
> finally {
> currentDbHandle = null;
> }
> }
>
> If currentDbHandle is null nothing happends to this open connection.
> I changed it to:
> if (currentDbHandle == null) {
> try {
> currentDbHandle = getIscDBHandle();
> }
> catch (XAException xae) {
> System.out.println(getClass().getName() + " /
> XAException " + xae.getMessage());
> }
> }
> if (currentDbHandle != null) {
> try {
> // if (log!=null) log.debug("in
> ManagedConnection.destroy",new Exception());
> .....
>
> What do you think.
> Did i do something wrong before reaching this? I do not understand wher
> this currentDbHandle is set, so maybe the problem is somewhere else....
>
> Greetings
>
> Stefan Mühlemann