Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 31564 invoked from network); 22 Jun 2006 14:40:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Jun 2006 14:40:07 -0000 Received: (qmail 32533 invoked by uid 500); 22 Jun 2006 14:39:50 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 32500 invoked by uid 500); 22 Jun 2006 14:39:50 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 32476 invoked by uid 99); 22 Jun 2006 14:39:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Jun 2006 07:39:50 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jeffgbutler@gmail.com designates 66.249.92.172 as permitted sender) Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Jun 2006 07:39:49 -0700 Received: by ug-out-1314.google.com with SMTP id k3so527084ugf for ; Thu, 22 Jun 2006 07:39:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ntI34XnswLMWprGuI3R60CzjNHvWwm74c6i6/qP6Sc8ljvMrRee+LVnwgspSyhGqfNO5q1ttvXyVv5c9FJ64CNJVFETcNCnTqItQpM8wBCdQlbYSwS345E5ydwVRyiDfPUMmQPSHSz2ZEybiVP+bgvznrEmeOJGg4LRGuhhRgMY= Received: by 10.67.89.5 with SMTP id r5mr1141201ugl; Thu, 22 Jun 2006 07:39:28 -0700 (PDT) Received: by 10.66.238.18 with HTTP; Thu, 22 Jun 2006 07:39:27 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 09:39:27 -0500 From: "Jeff Butler" To: user-java@ibatis.apache.org Subject: Re: Websphere 6 + iBatis + DB2 iSeries problem In-Reply-To: <54953.57.66.141.2.1150985977.squirrel@www.kepler.ro> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_269_29451306.1150987167781" References: <28169.57.66.141.2.1150971103.squirrel@www.kepler.ro> <54953.57.66.141.2.1150985977.squirrel@www.kepler.ro> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_269_29451306.1150987167781 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Please give it a try with the transaction configuration I sent previously. EXTERNAL will not work unless there are EJBs - the transactions are never being committed and that's why WebSphere is holding on to them. JDBC should work, but I'm certain that JTA will work because that's what we use in our non-EJB applications. Jeff Butler On 6/22/06, cantohi@kepler-rominfo.com wrote: > > Hi, > > We are not using EJB but we have tested with: > - transaction manager type="JDBC" and type="EXTERNAL" > > but we have same problem ... after a while, the connection pool becomes > full, nothing is executed on database. > > Websphere says all the connection are IN USE ... > > In our code, usually it stops working in between of 2 DAO calls. > > eg. > dao.selectX() > dao.selectY() > dao.selectZ() > > In the log for java.sql.* we can see that dao.selectX() and dao.selectY > are executed but dao.selectZ() not. The problem is that we are requesting > different functionalities and when it stops working (pool at 100% ... > timeout getting connection), it stops in different places per each request > ... so we cannot say that dao.selectZ() caused the problem. > > Any clue please? > > Thank you, > Cornel > > > I doubt this is an iBATIS issue. We have a large appliation using WAS6, > > DB2, iBATIS and don't see these problems. > > > > With your transaction configuration you are relying on WebSphere to > commit > > the transactions. To me, this implies you are using EJBs - so I would > > check > > the EJB configuration first to see if you've properly configured the > > transactional behavior of the EJBs. > > > > If you are not using EJBs, then this transaction configuration is not > > appropriate on WebSphere - unless you've configured some proprietary > > WebSphere extensions to deal with container managed transactions with > > servlets. If you are not using EJBs, then this is a more appropriate > > transaction configuration: > > > > > > > > > > > > > > > > > > Jeff Butler > > > > > > > > On 6/22/06, cantohi@kepler-rominfo.com > wrote: > >> > >> Hi, > >> > >> We are facing a very big problem with WAS6 + iBatis 2.1.5 + DB3 iSeries > >> (V%R3M0). > >> > >> We are performing the stressing test and after a while (usually 30-60 > >> minutes) af activity, the connection pool from Websphere become full > >> (100 > >> connections allocated from 100) and everything is stucked. This happens > >> in > >> 2 minutes and before everithing is going very smoothly ... > >> > >> We have tried many configuration like: > >> - lazyLoadingEnabled="false" > >> > >> > >> > >> > >> > >> > >> > >> > >> There is no error message except "Timeout waiting for free connection > >> ...". > >> > >> On iSeries we are seeing all 100 connections open but nothing si locked > >> (rows, tables), nothing runs in each connection ... seems like they are > >> in > >> wait. > >> > >> On Websphere we see: > >> com.ibm.ws.LocalTransaction.LocalTranCoordImpl@2993a251;RUNNING; > >> MCWrapper id 828224d Managed connection > >> WSRdbManagedConnectionImpl@4c58624c State:STATE_TRAN_WRAPPER_INUSE > >> Thread > >> Id: 5b75a268 Thread Name: WebContainer : 74 Handle count 0 > >> > >> We are asking if they may be some problems between iBatis and Websphere > >> ... > >> > >> Please help! > >> > >> Thank you, > >> Cornel > >> > >> > > > > ------=_Part_269_29451306.1150987167781 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Please give it a try with the transaction configuration I sent previously.
 
EXTERNAL will not work unless there are EJBs - the transactions are never being committed and that's why WebSphere is holding on to them.
 
JDBC should work, but I'm certain that JTA will work because that's what we use in our non-EJB applications.
 
Jeff Butler

 
On 6/22/06, cantohi@kepler-rominfo.com <cantohi@kepler-rominfo.com > wrote:
Hi,

We are not using EJB but we have tested with:
- transaction manager type="JDBC" and type="EXTERNAL"

but we have same problem ... after a while, the connection pool becomes
full, nothing is executed on database.

Websphere says all the connection are IN USE ...

In our code, usually it stops working in between of 2 DAO calls.

eg.
dao.selectX()
dao.selectY()
dao.selectZ()

In the log for java.sql.* we can see that dao.selectX() and dao.selectY
are executed but dao.selectZ() not. The problem is that we are requesting
different functionalities and when it stops working (pool at 100% ...
timeout getting connection), it stops in different places per each request
... so we cannot say that dao.selectZ() caused the problem.

Any clue please?

Thank you,
Cornel

> I doubt this is an iBATIS issue.  We have a large appliation using WAS6,
> DB2, iBATIS and don't see these problems.
>
> With your transaction configuration you are relying on WebSphere to commit
> the transactions.  To me, this implies you are using EJBs - so I would
> check
> the EJB configuration first to see if you've properly configured the
> transactional behavior of the EJBs.
>
> If you are not using EJBs, then this transaction configuration is not
> appropriate on WebSphere - unless you've configured some proprietary
> WebSphere extensions to deal with container managed transactions with
> servlets.  If you are not using EJBs, then this is a more appropriate
> transaction configuration:
>
> <transactionManager type="JTA" commitRequired="true">
>   <property name="UserTransaction" value="java:comp/UserTransaction"/>
>   <dataSource type="JNDI">
>     <property name="DataSource" value="${DBSOURCE}"/>
>   </dataSource>
> </transactionManager>
>
> Jeff Butler
>
>
>
> On 6/22/06, cantohi@kepler-rominfo.com <cantohi@kepler-rominfo.com> wrote:
>>
>> Hi,
>>
>> We are facing a very big problem with WAS6 + iBatis 2.1.5 + DB3 iSeries
>> (V%R3M0).
>>
>> We are performing the stressing test and after a while (usually 30-60
>> minutes) af activity, the connection pool from Websphere become full
>> (100
>> connections allocated from 100) and everything is stucked. This happens
>> in
>> 2 minutes and before everithing is going very smoothly ...
>>
>> We have tried many configuration like:
>> - lazyLoadingEnabled="false"
>> <transactionManager commitRequired="true" type="EXTERNAL" >
>>      <property name="DefaultAutoCommit" value="false" />
>>      <property name="SetAutoCommitAllowed" value="false" />
>>      <dataSource type="JNDI">
>>               <property name="DataSource" value="${DBSOURCE}"/>
>>        </dataSource>
>> </transactionManager>
>>
>> There is no error message except "Timeout waiting for free connection
>> ...".
>>
>> On iSeries we are seeing all 100 connections open but nothing si locked
>> (rows, tables), nothing runs in each connection ... seems like they are
>> in
>> wait.
>>
>> On Websphere we see:
>> com.ibm.ws.LocalTransaction.LocalTranCoordImpl@2993a251 ;RUNNING;
>> MCWrapper id 828224d  Managed connection
>> WSRdbManagedConnectionImpl@4c58624c  State:STATE_TRAN_WRAPPER_INUSE
>> Thread
>> Id: 5b75a268 Thread Name: WebContainer : 74 Handle count 0
>>
>> We are asking if they may be some problems between iBatis and Websphere
>> ...
>>
>> Please help!
>>
>> Thank you,
>> Cornel
>>
>>
>


------=_Part_269_29451306.1150987167781--