Subject | Question on FBManagedConnection.cleanup() |
---|---|
Author | agent82_a |
Post date | 2004-07-11T10:03:43Z |
Hi,
I checked-out the jaybird sourcecodes from the CVS and opened
FBManagedConnection.cleanup() method.
public void cleanup() throws ResourceException
{
for (Iterator i = connectionHandles.iterator(); i.hasNext();)
{
((AbstractConnection)i.next()).setManagedConnection(null);
} // end of for ()
connectionHandles.clear();
}
Would it be safe if we add a line
this.currentTr = null;
just after connectionHandles.clear(); ?
The reason for adding that an extra line to reset the currentTr is
that sometimes, I would get this kind of exception (under a
transacted environment) during resource de-listment:
2004-05-05 10:31:15,966 WARN [org.jboss.tm.TransactionImpl]
XAException: tx=TransactionI
mpl:XidImpl [FormatId=257, GlobalId=appserver01//11103, BranchQual=]
errorCode=XAER_NOTA
org.firebirdsql.jca.FBXAException: Unrecognized transaction at
org.firebirdsql.jca.FBManagedConnection.internalEnd
(FBManagedConnection.java:437)
at org.firebirdsql.jca.FBManagedConnection.end
(FBManagedConnection.java:409)
at org.jboss.tm.TransactionImpl.endResource
(TransactionImpl.java:1205)
at org.jboss.tm.TransactionImpl.delistResource
(TransactionImpl.java:543)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnection
EventList
ener.delist(TxConnectionManager.java:505)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnection
EventList
ener.connectionClosed(TxConnectionManager.java:554)
at org.firebirdsql.jca.FBManagedConnection$2.notify
(FBManagedConnection.java:1176
)
at org.firebirdsql.jca.FBManagedConnection.notify
(FBManagedConnection.java:1157)
at org.firebirdsql.jca.FBManagedConnection.close
(FBManagedConnection.java:846)
at org.firebirdsql.jdbc.AbstractConnection.close
(AbstractConnection.java:437)
After delisting a resource, our appserver will usually return the
managedConnection back to the pool. And if the process of delisting
a resource fails like what I have experienced above, that managed
connection will also be marked for disposal. However, the appserver
won't be able to successfully invoke destroy() since the currentTr
variable is still registered as not null. Thus leading to a
connection leakage.
I checked-out the jaybird sourcecodes from the CVS and opened
FBManagedConnection.cleanup() method.
public void cleanup() throws ResourceException
{
for (Iterator i = connectionHandles.iterator(); i.hasNext();)
{
((AbstractConnection)i.next()).setManagedConnection(null);
} // end of for ()
connectionHandles.clear();
}
Would it be safe if we add a line
this.currentTr = null;
just after connectionHandles.clear(); ?
The reason for adding that an extra line to reset the currentTr is
that sometimes, I would get this kind of exception (under a
transacted environment) during resource de-listment:
2004-05-05 10:31:15,966 WARN [org.jboss.tm.TransactionImpl]
XAException: tx=TransactionI
mpl:XidImpl [FormatId=257, GlobalId=appserver01//11103, BranchQual=]
errorCode=XAER_NOTA
org.firebirdsql.jca.FBXAException: Unrecognized transaction at
org.firebirdsql.jca.FBManagedConnection.internalEnd
(FBManagedConnection.java:437)
at org.firebirdsql.jca.FBManagedConnection.end
(FBManagedConnection.java:409)
at org.jboss.tm.TransactionImpl.endResource
(TransactionImpl.java:1205)
at org.jboss.tm.TransactionImpl.delistResource
(TransactionImpl.java:543)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnection
EventList
ener.delist(TxConnectionManager.java:505)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnection
EventList
ener.connectionClosed(TxConnectionManager.java:554)
at org.firebirdsql.jca.FBManagedConnection$2.notify
(FBManagedConnection.java:1176
)
at org.firebirdsql.jca.FBManagedConnection.notify
(FBManagedConnection.java:1157)
at org.firebirdsql.jca.FBManagedConnection.close
(FBManagedConnection.java:846)
at org.firebirdsql.jdbc.AbstractConnection.close
(AbstractConnection.java:437)
After delisting a resource, our appserver will usually return the
managedConnection back to the pool. And if the process of delisting
a resource fails like what I have experienced above, that managed
connection will also be marked for disposal. However, the appserver
won't be able to successfully invoke destroy() since the currentTr
variable is still registered as not null. Thus leading to a
connection leakage.