Subject | FBManagedConnection forgetting physical connections |
---|---|
Author | Bart Van Cutsem |
Post date | 2003-03-10T09:50:57Z |
Hello
We've deployed a JBoss app (JBoss 3.0.6) with accompanying web app using a
Firebird (1.0.2) backend together with Jaybird (latest CVS version, using the
JGDS implementation). I've configured a data source, like the example supplied
with JBoss, with the XaTXConnectionManager. Problem is, after a while we get
loads of DB connections that don't seem to be active but make Firebird sort of
"barf up" after which all connections are abandoned. I've been adding some log
lines here and there to find out what goes on and found out this:
- at a certain moment in time a DB connection is queried for use:
org.firebirdsql.jdbc.FBDataSource.getConnection()
- this call walks through some Xa transaction stuff of JBoss itself and ends
up in org.firebirdsql.jca.FBManagedConnection.start(), apparently to start a
global transaction
- this executes internalstart() and goes on to findIscTrHandle() in
FBManagedConnection
In findIscTrHandle I see following lines of code:
1.
currentTr = mcf.getCurrentIscTrHandle(xid, this, flags);
2.
mcf.returnDbHandle(currentDbHandle, cri);
3.
if (currentTr.getDbHandle() != currentDbHandle)
{
try
{
....
....
currentDbHandle = currentTr.getDbHandle();
I thought that each FBManagedConnection object was associated with 1 DB handle
but only when the first FBManagedConnection object is picked up from the pool,
in statement 3. both handles are the same. When the following
FBManagedConnection objects are picked up, the handles mismatch, the xid seems
to be the same as for the first FBManagedConnection object, and as a result I
get a number of ManagedConnection objects pointing to the same physical
connection. When a pool cleanup occurs, one cleanup succeeds, the following
few try to clean up the same connection (which is silently ignored in the
code), and, off course, the "abandoned" connections stay alive. After a while
Firebird starts acting up before they get garbage collected (if they ever get
garbage collected).
Another question: you can configure the connection pool with a min and max
size. But I see all idle connections are always cleaned up when the idle
remover runs. I thought a pool would grow in size and then shrink again when
some connections stay idle. When all connections are idle, they all are
cleaned up and the pool refills to minimum size. Is this how it's supposed to
be?
Regards
Bart
We've deployed a JBoss app (JBoss 3.0.6) with accompanying web app using a
Firebird (1.0.2) backend together with Jaybird (latest CVS version, using the
JGDS implementation). I've configured a data source, like the example supplied
with JBoss, with the XaTXConnectionManager. Problem is, after a while we get
loads of DB connections that don't seem to be active but make Firebird sort of
"barf up" after which all connections are abandoned. I've been adding some log
lines here and there to find out what goes on and found out this:
- at a certain moment in time a DB connection is queried for use:
org.firebirdsql.jdbc.FBDataSource.getConnection()
- this call walks through some Xa transaction stuff of JBoss itself and ends
up in org.firebirdsql.jca.FBManagedConnection.start(), apparently to start a
global transaction
- this executes internalstart() and goes on to findIscTrHandle() in
FBManagedConnection
In findIscTrHandle I see following lines of code:
1.
currentTr = mcf.getCurrentIscTrHandle(xid, this, flags);
2.
mcf.returnDbHandle(currentDbHandle, cri);
3.
if (currentTr.getDbHandle() != currentDbHandle)
{
try
{
....
....
currentDbHandle = currentTr.getDbHandle();
I thought that each FBManagedConnection object was associated with 1 DB handle
but only when the first FBManagedConnection object is picked up from the pool,
in statement 3. both handles are the same. When the following
FBManagedConnection objects are picked up, the handles mismatch, the xid seems
to be the same as for the first FBManagedConnection object, and as a result I
get a number of ManagedConnection objects pointing to the same physical
connection. When a pool cleanup occurs, one cleanup succeeds, the following
few try to clean up the same connection (which is silently ignored in the
code), and, off course, the "abandoned" connections stay alive. After a while
Firebird starts acting up before they get garbage collected (if they ever get
garbage collected).
Another question: you can configure the connection pool with a min and max
size. But I see all idle connections are always cleaned up when the idle
remover runs. I thought a pool would grow in size and then shrink again when
some connections stay idle. When all connections are idle, they all are
cleaned up and the pool refills to minimum size. Is this how it's supposed to
be?
Regards
Bart