ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cant...@kepler-rominfo.com
Subject Re: Websphere 6 + iBatis + DB2 iSeries problem
Date Thu, 22 Jun 2006 17:25:22 GMT
Hi Jeff,

Thanks for the link.
I am almost sure that our code is working well ... before using iBatis we
used it for applications using JDBC only and we had no problems even for
applications with similar size.

I am not 100% sure that our problem is not related with iBatis. Our
opinion is that our problem is between WAS, iBatis, JDBC Driver ... seems
like the connections are not returned to the free pool and remains in a
"in use" state ... I am not sure what is causing this problem.

As I said, the symthoms are:
- WAS Connection pool become fully allocated and get stucked ... no user
can obtain a connection

OR/AND

- WAS Thread Pool become fully allocation and get stucked (and Connection
Pool is at 60%)

This happens after running the application in a stress conditions for 60
minutes ... before only 5-10% of the Threads/Connections available are
used and suddently, in 2 minutes, everything is stucked ...

Thank you,
Cornel


> No - the iBATIS configuration does not change anything about how the
> WebSphere connection pool or transactions work.  What I am saying is that
> if
> you go outside of iBATIS for some of your selects, then you need to make
> sure that your JDBC code is correct for the environment in which you are
> running.
>
> So in WebSphere, you should look up the datasource from JNDI, look up the
> transaction from JNDI, demarcate the transactions correctly according to
> the
> JTA spec, and make sure that all connections are closed after they are
> used.
>
> This link in the WebSphere documentation is a good starting point for
> investigating:
>
> http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tjta_ep.html
>
> You could also look at the source code the the iBATIS JTA transaction
> manager - this would give you a good model of how you should build your
> own
> transaction management service for WebSphere.
>
> I think this thread is getting a little off topic for the list - this is
> not
> an iBATIS issue, but more of an issue about understanding the WebSphere
> transaction environment.
>
> Jeff Butler
>
>
>
> On 6/22/06, cantohi@kepler-rominfo.com <cantohi@kepler-rominfo.com> wrote:
>>
>> Hi Jeff,
>>
>> My application does not create additional Thread.
>>
>> About JTA, you are saying if we are setting iBatis to use JTA, we also
>> have to change our JDBC code?
>>
>> We are using Select + Scrollable ResultSet in order to move the cursoer
>> to
>> a specific position in the ResultSet ... this couldn't be handled via
>> iBatis as I know ...
>>
>> Thank you,
>> Cornel
>>
>>
>> > 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, cantohi@kepler-rominfo.com <cantohi@kepler-rominfo.com>
>> 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, 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
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>


Mime
View raw message