ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Websphere 6 + iBatis + DB2 iSeries problem
Date Thu, 22 Jun 2006 16:56:34 GMT
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