Can you provide some example code from your application, showing some crud operations?
Clinton On 2009-04-03, Jeff Hibbs <jhi...@bop.gov> wrote: > Hello All - > > Any help will be greatly appreciated...Thanks!!! > > Our iBatis-based 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 replaced glassfish with Tomcat and the problem went away > > 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 Glassfish? > > 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/@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) > > > > > > > > > > -- Sent from my mobile device
