This sounds like a different problem than what you first reported. The thread pool being 100% utilized implies theoretically infinite response time. In performance theory, the response time multiplier is 1/(1 - Utilization) - so there's a real problem with 100% utilization!
Is your application starting any additional threads? iBATIS does not start any additional threads itself. If you're hitting the app with some kind of load tester you might need to increase the "think time" in the load tester. Or you could increase the thread pool if you really believe that there will be that much concurrent activity in production.
If you're app is starting additional threads, you need to make sure that they are ending appropriately.
What kind of select cannot be executed with iBATIS? I've never heard of such a thing :) If you're going outside of iBATIS for some of your selects, then you need to make sure that transactions are committed and closed. In theory it should work, but it depends on the quality of your hand written JDBC code - JTA code can be a little tricky.
Jeff Butler
On 6/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
Hi Jeff,
We have the folowing problem:
- WAS Thread Pool is at 100%
- WAS Connection Pool is at 66% and do not increase.
The system runs very slow ... I have the feeling that many Threads are
stucked as well as the Connections. There are very few Threads handling
requests (from IE browser).
One more info:
- in our application we are using WAS DataSource
- we are using iBatis and Struts
- in some of the Struts acctions we are invoking iBatis DAO layer
executing SQL selects as well as we are getting connections directly from
the WAS DataSource executing other Selects (that cannot be executed via
iBatis).
May this mix of Connection handling causing our problems?
Thank you,
Cornel
> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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, [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
>> >>
>> >>
>> >
>>
>>
>
