Hello All -
Any help will be greatly appreciated...Thanks!!!
Our iBatis-based (iBATIS is a lightweight ORM) application was running on Sun1 Server/DB2 Version 8 - z/OS with no problems. When we migrated to Glassfish V2, the DB folks noticed many idle threads coming from our application which uses iBATIS 2.1.5 (July 2005 Build). Other (non-iBATIS) applications that use straight JDBC (no ORM) on the same server, using the same connection pool, were not causing idle threads. Below is a sample what the DBA is seeing:
—---------------------------------------------------------------------------------------------------------------------
Primauth Planname name ID Status elapsed time CPU time
xxxxxxxxx DISTSERV SYSLN100 SERVER *DB2 5:23.78195 0.000969
xxxxxxxxx DISTSERV SYSLN100 SERVER *DB2 5:23.67919 0.001146
xxxxxxxxx DISTSERV SYSLN100 SERVER *DB2 5:23.59251 0.000896
xxxxxxxxx DISTSERV SYSLN100 SERVER *DB2 5:18.40476 0.001567
xxxxxxxxx DISTSERV SYSLN100 SERVER *DB2 5:18.38349 0.001066
14.46.15 STC12568 DSNL028I #J3P1 GAD00841.K6FE.C3F92EF69C21=157421 914
914 ACCESSING DATA FOR
914 LOCATION xx.xxx.x.xx
914 IPADDR xx.xxx.x.xx
14.48.14 STC12568 DSNL027I #J3P1 SERVER DISTRIBUTED AGENT WITH 561
561 LUWID=GAD00840.PC1B.C3F92F10E401=157523
561 THREAD-INFO=xxxxxx:genie4:xxxxxxx:db2jcc_applic
561 RECEIVED ABEND=04E
561 FOR REASON=00D3003B
14.48.14 STC12568 DSNL027I #J3P1 SERVER DISTRIBUTED AGENT WITH 562
562 LUWID=GAD00840.PC20.C3F92F1B5DDF=157544
562 THREAD-INFO=xxxxxxx:genie4:xxxxxxx:db2jcc_applic
562 RECEIVED ABEND=04E
562 FOR REASON=00D3003B
—-----------------------------------------------------------------------------------------------------------------------
I'm not going to pretend to know what all this means, but apparently iBATIS/Glassfish is not releasing the threads after the SQL completes. Again, other non-iBATIS applications using the same connection pool are not generating these ilde threads. From a user's perspective the system is running fine - the queries are returning quickly. Also, we are not exhausting the connections in the connection pool, but apparently some resources in DB2 are incorrectly being left open. I guess I'm not sure of the difference between a "connection" and a "thread" from the DB2 perspective.
We have been able to replicate this in the Test env. Here's what we know so far:
- Tried iBATIS 2.3.3.720: same results
- Used the SIMPLE data source (a connection pool implemented by iBATIS), by passing the GlassFish connection pool and did NOT have the problem.
- Replaced glassfish with Tomcat and did NOT have the problem,
Obvious questions:
1. Why are the iBATIS queries keeping idle threads open on DB2 while the straight JDBC coded queries are not.
2. Why does this only appear to happen with the GlassFish connection pool?
Here's our iBATIS config:
<settings
useStatementNamespaces="false"
cacheModelsEnabled="true"
enhancementEnabled="true"
/>
<transactionManager type="JDBC" >
<dataSource type="JNDI">
<property name="DataSource" value="java:comp/env/_at_isds.datasource.name@"/>
</dataSource>
</transactionManager>
.......
TEST Connection Pool Info:
Datasource Classname: com.ibm.db2.jcc.DB2DataSource (prod same)
Resource Type:javax.sql.DataSource (prod same)
Pool Settings:
Initial and Minimum Pool Size:8 (prod = 0)
Maximum Pool Size: 32 (prod = 300)
Pool Resize Quantity: 2 (prod = 5)
Idle Timeout: 300 (prod = 15)
Max Wait Time:60000 (prod = 60000)
Again, Thanks!
[Message sent by forum member 'jjhibbs' (jjhibbs)]
http://forums.java.net/jive/thread.jspa?messageID=341827