ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janne mattila <jans...@luukku.com>
Subject Re: TransactionManager config for simultaneous EXTERNAL and JDBC transactions
Date Tue, 05 Jun 2007 20:17:54 GMT
The code neither commits or rolls back with EXTERNAL yet - I am only at the design phase at
the moment... 

Are you saying that if 
- I use EXTERNAL transaction manager
- transaction is handled by the EJB container (transaction starts when EJB method is called,
commits when method ends successfully, and rolls back if unchecked exception is thrown or
context.setRollbackOnly() has been called)
- I execute the example code, i != 42, so daoManager.commitTransaction is _not_ called before
daoManager.endTransaction
- no exceptions are thrown out of the EJB method

so are you saying that in this case the transaction is rolled back? In that case iBatis would
have to set the external transaction to "rollback only" - does it do that? 

Jeff Butler kirjoitti 05.06.2007 kello 21:50:
> If it's committing with EXTERNAL then you can be sure that your external
> transaction manager is doing the commit - NOT iBATIS.
> 
> My guess is that you don't really have an external transaction
>  manager and
> DB autocommit is kicking in.  Either that, or you've not properly
>  managed
> the rollback with whatever external transaction manager you are using.
> 
> If you put the code you mentioned into debug and stepped through it you
> would never see a commit with the EXTERNAL transaction manager.
> 
> Jeff Butler
> 
> 
> 
> On 6/5/07, janne mattila <jansu76@luukku.com> wrote:
> >
> > > The book is referring to the fact that you can leave the transaction
> > >  code in
> > > your DAOs and use different configurations.  For example, one
> > > SqlMapConfig.xml that specifies JDBC/SIMPLE, another that specifies
> > > EXTERNAL/JNDI - the same code will work unmodified.  When you use
> > >  EXTERNAL,
> > > the rollback methods are no-op methods so there's no harm in leaving
> > >  them in
> > > the code.
> >
> > Yeah, well, that was exactly my point. Example code:
> >
> > daoManager.startTransaction;
> > try {
> > someDao.doSomeUpdate();
> > int result = someDao.selectSomeData();
> > if (result = 42) {
> >   // everything is fine, commit
> >   daoManager.commitTransaction();
> > } else {
> >   // wrong value, need to rollback (no exception)
> > }
> > } finally {
> > daoManager.endTransaction;
> > }
> >
> > does _not_ work unmodified with different configurations. With JDBC config
> > it rolls back when result != 42, and with EXTERNAL config it commits. For
> > sure you _can_ implement methods that work unmodified, you just need to be
> > aware of this....
> >
> > I think it would be easier to implement methods that work identically in
> > all configs if daoManager had a rollbackTransaction method, but it does
> not.
> >
> >
> > Jeff Butler kirjoitti 05.06.2007 kello 16:40:
> > > Sure - but this is normal.  If you throw an unchecked exception, the
> > > container will roll-back the transaction.  If you throw a checked
> > >  exception,
> > > you'll need to call context.setRollbackOnly().
> > >
> > > The book is referring to the fact that you can leave the transaction
> > >  code in
> > > your DAOs and use different configurations.  For example, one
> > > SqlMapConfig.xml that specifies JDBC/SIMPLE, another that specifies
> > > EXTERNAL/JNDI - the same code will work unmodified.  When you use
> > >  EXTERNAL,
> > > the rollback methods are no-op methods so there's no harm in leaving
> > >  them in
> > > the code.
> > >
> > > Jeff Butler
> > >
> > >
> > > On 6/5/07, janne mattila <jansu76@luukku.com> wrote:
> > > >
> > > > Basically this means then that I need to ensure that methods that
> > should
> > > > cause rollback throw an exception which gets thrown from the EJB (and
> > this
> > > > causes rollback for the EJB transaction).
> > > >
> > > > "iBatis in Action" mentions how you can switch from local to global
> > > > transactions and still use the same code without modifications. Well,
> > this
> > > > is not exactly true then, or at least you need to ensure that you
> > don't
> > > have
> > > > code which causes rollback when using local transactions (by calling
> > > > endTransaction without calling commitTransaction) without throwing
> > > > exceptions, as this would not cause a rollback when using a global
> > (EJB)
> > > > transaction.
> > > >
> > > > as in, following code would cause problems:
> > > >
> > > > daoManager.startTransaction;
> > > > try {
> > > > someDao.doSomeUpdate();
> > > > int result = someDao.selectSomeData();
> > > > if (result = 42) {
> > > >    // everything is fine, commit
> > > >    daoManager.commitTransaction();
> > > > } else {
> > > >    // wrong value, need to rollback (no exception)
> > > > }
> > > > } finally {
> > > > daoManager.endTransaction;
> > > > }
> > > >
> > > >
> > > >
> > > > Jeff Butler kirjoitti 05.06.2007 kello 15:32:
> > > > > When using EXTERNAL transaction manager the start, end, and commit
> > > > >  methods
> > > > > do nothing.  It is expected that the EXTERNAL manager is dealing
> > with
> > > > > commit.  EXTERNAL is used with EJB container managed transactions
> > > > >  where the
> > > > > EJB conteiner handles all transactions.
> > > > >
> > > > > At the risk of speaking heresy...why don't you have a stateless
> > > > >  session EJB
> > > > > facade that handles transactions?  The JSP/Action tier can easily
> > > > >  call the
> > > > > EJB methods.  If you want to have a different EJB layer for other
> > > > >  clients,
> > > > > that layer can easily propogate it's transaction to the EJB facade.
> > > > >  Simple!
> > > > >
> > > > > Or, if you've drunk the Spring kool-aid, you can use Spring to
> > inject a
> > > > > transaction manager into the iBATIS config differently for different
> > > > > clients.
> > > > >
> > > > > Jeff Butler
> > > > >
> > > > >
> > > > >
> > > > > On 6/5/07, janne mattila <jansu76@luukku.com> wrote:
> > > > > >
> > > > > > Follow-up question: what happens when EXTERNAL transaction manager
> > is
> > > > > > used, transaction is started with DaoManager.startTransaction,
and
> > > > > > transaction is ended using DaoManager.endTransaction and
> > transaction
> > > > has
> > > > > > _not_ been committed using DaoManager.commitTransaction?
> > > > > >
> > > > > > Does this cause the external transaction to be rolled back (like
> > it
> > > > would
> > > > > > cause a JDBC transaction to be rolled back)?
> > > > > >
> > > > > > janne mattila kirjoitti 05.06.2007 kello 15:10:
> > > > > > > I am implementing a system which has a number of iBatis
DAOs
> > that
> > > > > > >  are used
> > > > > > > both by EJB clients and basic web application code.
> > > > > > >
> > > > > > > Architecture will be like
> > > > > > >
> > > > > > > (EJB)
> > > > > > > (JSPs/Actions etc)
> > > > > > >   |
> > > > > > >   |
> > > > > > >   |
> > > > > > > (business logic layer)
> > > > > > >   |
> > > > > > >   |
> > > > > > >   |
> > > > > > > (DAOs)
> > > > > > >
> > > > > > > EJBs use container managed transactions, and hence I should
use
> > > > EXTERNAL
> > > > > > > transaction manager.
> > > > > > >
> > > > > > > Web application code should use basic iBatis JNDI/SIMPLE
> > transaction
> > > > > > > manager and transactions are demarcated on the business
logic
> > layer
> > > > > > >  using
> > > > > > > daoManager.startTransaction() etc.
> > > > > > >
> > > > > > > Both "business logic clients" (EJB & web app code)
should use
> > the
> > > > same
> > > > > > > business logic methods (which use the same DAO code). I
> > understand I
> > > > can
> > > > > > > use the same business logic layer for both, since for example
> > > > > > > daoManager.commitTransaction() will not do anything if
EXTERNAL
> > > > > > > transactions are configured?
> > > > > > >
> > > > > > > How should iBatis configuration be done??? Do I have to
have
> > > > separate
> > > > > > > dao1.xml and dao2.xml files and build separate DaoManager
> > instances
> > > > > > >  for the
> > > > > > > EJB clients and the web app clients?
> > > > > > >
> > > > > > > Anything specific that I need to worry about using this
> > approach?
> > > > > > >
> > > > > > >
> > ...................................................................
> > > > > > > Luukku Plus paketilla pääset eroon tila- ja
> > turvallisuusongelmista.
> > > > > > > Hanki Luukku Plus ja helpotat elämääsi.
> > http://www.mtv3.fi/luukku
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ...................................................................
> > > > > > Luukku Plus paketilla pääset eroon tila- ja
> > turvallisuusongelmista.
> > > > > > Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku
> > > > > >
> > > > > >
> > > >
> > > >
> > > > ...................................................................
> > > > Luukku Plus paketilla pääset eroon tila- ja turvallisuusongelmista.
> > > > Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku
> > > >
> > > >
> >
> >
> > ...................................................................
> > Luukku Plus paketilla pääset eroon tila- ja turvallisuusongelmista.
> > Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku
> >
> >


...................................................................
Luukku Plus paketilla pääset eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku


Mime
View raw message