ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Maves <nathan.ma...@gmail.com>
Subject Re: Idle Threads - Glassfish/DB2
Date Fri, 03 Apr 2009 14:29:47 GMT
Jeff,
Not to state the obvious but it does not seem like an ibatis issue.  It
sounds more like the connection pool implementation of Glassfish.  As a test
you might try creating your own connection pool using the SIMPLE datasource
type in ibatis just to ensure that it is an issue with Glassfish.

Nathan

On Fri, Apr 3, 2009 at 8:15 AM, Jeff Hibbs <jhibbs@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)
>
>
>
>
>
>
>
>
>
>

Mime
View raw message