Hi,
reapTime=180
Unsed Timeout=1800
Aged Timeout=0
Regarding Aged Timeout, if the connection is considered as "in
transaction", WAS never close it ... here is the info related to each
connection that is in pool considered at in use but it is stucked:
[EMAIL PROTECTED];RUNNING;
MCWrapper id 29aed4e5 Managed connection
[EMAIL PROTECTED] State:STATE_TRAN_WRAPPER_INUSE Thread
Id: 5e029746 Thread Name: WebContainer : 75 Handle count 1
Thank you,
Cornel
> What are the Reap Time, Aged Timeout and Unused Timeout settings for your
> application server?
>
> Maybe WAS never releases the connections
>
> [EMAIL PROTECTED] schrieb am 22.06.2006 16:19:37:
>
>> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> 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:
>> >> [EMAIL PROTECTED];RUNNING;
>> >> MCWrapper id 828224d Managed connection
>> >> [EMAIL PROTECTED] 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
>> >>
>> >>
>> >
>>
>
