TConnectionManager deadlock issue

I have a client who is getting the following problem: They have two threads which are trying to access the same collection through the TaminoAPI4J API. Both threads are using the TConnectionPoolManager to try and retrieve the collection. When they come in at just the right time (we can reproduce fairly readily), both threads deadlock and the application
is halted.

This is the program he is using:
private void getPooledConnection() throws EmrException
{
try
{
if(!TConnectionPoolManager.getInstance().hasPool(this.poolName))
{
TConnectionPoolManager.getInstance()
.addConnectionPool(this.poolName,
this.dbName,
this.poolDomain,
this.userName,
this.password,
this.poolMaxConn,
this.poolInitConn,
this.poolTimeOut);

}
this.connection =
TConnectionPoolManager.getInstance().getConnection(this.poolName);
}
catch (TConnectionNotAvailableException e)
{
throw new EmrException(“Failed to get a connection from the
pool”, e);
}
}



The Tamino version is 4.1.4.1, it’s a Windows 2000 machine (single processor), the application runs inside of Apache Tomcat.

This is the stack trace:
STACK TRACE – THREAD 1
=======================

Thread-5[1] where
[1] java.lang.Object.wait (native method)
[2]
com.softwareag.tamino.db.API.connection.TConnectionPoolImpl.getConnection
(null)
[3]
com.softwareag.tamino.db.API.connection.TConnectionPoolImpl.getConnection
(null)
[4]
com.softwareag.tamino.db.API.connection.TConnectionPoolManager.getConnecti
on (null)
[5] com.softwareag.emr.util.TaminoConnection.getPooledConnection
(TaminoConnec
tion.java:119)
[6] com.softwareag.emr.util.TaminoConnection.open
(TaminoConnection.java:63)
[7] com.softwareag.emr.util.TaminoConnection.open
(TaminoConnection.java:52)
[8] com.softwareag.emr.security.SessionManagerDAO.connect
(SessionManagerDAO.j
ava:204)
[9] com.softwareag.emr.security.SessionManagerDAO.get
(SessionManagerDAO.java:
87)
[10] com.softwareag.emr.security.SessionManager.getUser
(SessionManager.java:1
79)
[11] com.softwareag.emr.util.HeaderTag.getUser (HeaderTag.java:185)
[12] com.softwareag.emr.util.HeaderTag.doStartTag (HeaderTag.java:49)
[13] org.apache.jsp.UserManagement_jsp._jspx_meth_emr_header_0
(UserManagement
_jsp.java:232)
[14] org.apache.jsp.UserManagement_jsp._jspService
(UserManagement_jsp.java:94
)
[15] org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:137)
[16] javax.servlet.http.HttpServlet.service (HttpServlet.java:853)
[17] org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.ja
va:210)
[18] org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)

[19] org.apache.jasper.servlet.JspServlet.service (JspServlet.java:241)
[20] javax.servlet.http.HttpServlet.service (HttpServlet.java:853)
[21] org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(Applica
tionFilterChain.java:247)
[22] org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilt
erChain.java:193)
[23] org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValv
e.java:256)
[24]
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.in
vokeNext (StandardPipeline.java:643)
[25] org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:4
80)
[26] org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:995)
[27] org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValv


STACK TRACE – THREAD 2
=======================
[1] java.lang.Object.wait (native method)
[2]
com.softwareag.tamino.db.API.connection.TConnectionPoolImpl.getConnection
(null)
[3]
com.softwareag.tamino.db.API.connection.TConnectionPoolImpl.getConnection
(null)
[4]
com.softwareag.tamino.db.API.connection.TConnectionPoolManager.getConnecti
on (null)
[5] com.softwareag.emr.util.TaminoConnection.getPooledConnection
(TaminoConnec
tion.java:119)
[6] com.softwareag.emr.util.TaminoConnection.open
(TaminoConnection.java:63)
[7] com.softwareag.emr.util.TaminoConnection.open
(TaminoConnection.java:52)
[8] com.softwareag.emr.security.SessionManagerDAO.connect
(SessionManagerDAO.j
ava:204)
[9] com.softwareag.emr.security.SessionManagerDAO.removeByTime
(SessionManager
DAO.java:119)
[10] com.softwareag.emr.security.SessionManager.run
(SessionManager.java:86)


As you can see in frame 2 of both stacks, it is in the getConnection()
method and waiting for a lock to be released on
“some object”.

Please advice on what can be done to avoid this deadlock in the connection manager
Regards,
Sumeet Bhatia

I’m trying to get an answer for you. However, due to vacation of several people, it might take a couple of days. Sorry about that.

The current problem has been resolved.

The problem appears to have been with the client code reaching the maximum number of connections allocated to the particular connection pool.

There was a section of code in which we were doing a connect and not calling disconnect
on the connection allocated by the pool.

The only question they have is :
Shouldn’t the connection pool manager through an exception when this occurs (it says so in the docs)?

I wrote a little test trying to simulate your scenario.
The test creates 22 worker threads. Each worker gets a connection from the same pool, but does not close this connection (i.e. it does not return it back to the pool). The pool has a maxConnection of 20. The worker threads 21 and 22 get a TConnectionNotAvailableException as expected when they try to get their connection.
I got no deadlock. Does my little test simulate your szenario?

Stefan