[
https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin...
]
Jesper Pedersen updated JBJCA-1159:
-----------------------------------
Summary: ConnectionListener leaked if TSR throws IllegalStateException
(was: DB Connections leaked if TX is not active after retrieving a connection)
Fix Version/s: 1.0.25.Final
1.1.5.Final
1.2.0.Beta1
Affects Version/s: 1.1.4.Final
1.0.24.Final
(was: 1.0.19.Final)
There is a TSR.getTransactionKey() check, but that doesn't eliminate a race. So
IronJacamar needs to guard against its TSR usage.
In the future, open a forum thread before creating JIRAs. Thanks
ConnectionListener leaked if TSR throws IllegalStateException
-------------------------------------------------------------
Key: JBJCA-1159
URL:
https://issues.jboss.org/browse/JBJCA-1159
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: 1.0.24.Final, 1.1.4.Final
Environment: AS7 EAP6.1
Reporter: gui borland
Assignee: Jesper Pedersen
Priority: Critical
Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA
transaction. However, if the ongoing TX is not 'active' anymore the connection is
lost.
The code of AbstractPool demonstrates the problem. The call to getLock will throw an
exception if the current TX is not active anymore and the cl is not returned to the pool.
This issue can be reproduced on AS7 by using any EJB that requires a tx and does
something with a DB connection. Put a breakpoint in the code below after retrieving the
connectionlistener, and then wait for the transaction to timeout. Once that's done,
continue the thread. The connection is not release (can be seen in JMX)
We have noticed this problem regularly during our performance tests.
{code}
ConnectionListener cl = mcp.getConnection(subject, cri);
if (trace)
log.tracef("Got connection from pool tracked by transaction=%s tx=%s",
cl, trackByTransaction);
TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
Lock lock = getLock();
try
{
lock.lockInterruptibly();
}
catch (InterruptedException ie)
{
Thread.interrupted();
throw new ResourceException(bundle.unableObtainLock(), ie);
}
{code}
It seems this issue was introduced by changes done for
https://issues.jboss.org/browse/JBJCA-572
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira