Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <1181114980374.jansu76.11200.r3Ui0IF3NL-FsYDZV93ZKw@luukku.com>
Date: Wed, 6 Jun 2007 10:29:40 +0300 (EEST)
From: janne mattila <jansu76@luukku.com>
To: user-java@ibatis.apache.org
Subject: Re: TransactionManager config for simultaneous EXTERNAL and JDBC
 transactions
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yeah, stateless session bean facades or letting spring handle the transacti=
ons would be a practical solution here.=20

Even if those are not used, I can manage with a single service layer implem=
entation that can be used by both clients, but this then means that service=
 layer has to be coded in a specific way (making sure that methods that rol=
lback using endTransaction() without commitTransaction() also throw a certa=
in exception which causes EJB layer to setRollbackOnly).

Anyhow, these issues seem clearer to me now, thanks...


Jeff Butler kirjoitti 05.06.2007 kello 23:52:
> In this case, the transaction will be committed.  Since the iBATIS
> transactional methods are doing nothing, and setRollbackOnly() is not
> called, the EJB will commit the transaction.
>=20
> The "right" way to design these types of things is to have the DAOs be
> transaction neutral (no commit/rollback code).  Then there should be
>  another
> layer whose job is to manage transactions.  I suppose if you are
>  trying to
> have these two different implementations that you might need to have
> different implementations of the service layer.  This is a real
>  point in the
> favor of Spring's declarative transaction code.  But this is also a good
> reason to consider a stateless session facade for transaction management
> that could easily be used by both types of clients.  Transaction
>  management
> and propogation is one thing the EJBs are actually fairly decent at.
>=20
> Jeff Butler
>=20
>=20
>=20
> On 6/5/07, janne mattila <jansu76@luukku.com> wrote:
> >
> > 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 !=3D 42, so daoManager.commitTransactio=
n 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 "rollbac=
k
> > 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 exter=
nal
> > > 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 y=
ou
> > > 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 transact=
ion
> > > > >  code in
> > > > > your DAOs and use different configurations.  For example, one
> > > > > SqlMapConfig.xml that specifies JDBC/SIMPLE, another that specifi=
es
> > > > > 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 leav=
ing
> > > > >  them in
> > > > > the code.
> > > >
> > > > Yeah, well, that was exactly my point. Example code:
> > > >
> > > > daoManager.startTransaction;
> > > > try {
> > > > someDao.doSomeUpdate();
> > > > int result =3D someDao.selectSomeData();
> > > > if (result =3D 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 !=3D 42, and with EXTERNAL config it comm=
its.
> > For
> > > > sure you _can_ implement methods that work unmodified, you just nee=
d
> > to be
> > > > aware of this....
> > > >
> > > > I think it would be easier to implement methods that work identical=
ly
> > 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 transact=
ion
> > > > >  code in
> > > > > your DAOs and use different configurations.  For example, one
> > > > > SqlMapConfig.xml that specifies JDBC/SIMPLE, another that specifi=
es
> > > > > 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 leav=
ing
> > > > >  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 th=
at
> > > > should
> > > > > > cause rollback throw an exception which gets thrown from the EJ=
B
> > (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 y=
ou
> > > > don't
> > > > > have
> > > > > > code which causes rollback when using local transactions (by
> > calling
> > > > > > endTransaction without calling commitTransaction) without throw=
ing
> > > > > > exceptions, as this would not cause a rollback when using a glo=
bal
> > > > (EJB)
> > > > > > transaction.
> > > > > >
> > > > > > as in, following code would cause problems:
> > > > > >
> > > > > > daoManager.startTransaction;
> > > > > > try {
> > > > > > someDao.doSomeUpdate();
> > > > > > int result =3D someDao.selectSomeData();
> > > > > > if (result =3D 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 deal=
ing
> > > > 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 statele=
ss
> > > > > > >  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 t=
o
> > > > 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.startTransacti=
on,
> > 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 D=
AOs
> > > > 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 shou=
ld
> > 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 h=
ave
> > > > > > 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=E4=E4set eroon tila- ja
> > > > turvallisuusongelmista.
> > > > > > > > > Hanki Luukku Plus ja helpotat el=E4m=E4=E4si.
> > > > http://www.mtv3.fi/luukku
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ...................................................................
> > > > > > > > Luukku Plus paketilla p=E4=E4set eroon tila- ja
> > > > turvallisuusongelmista.
> > > > > > > > Hanki Luukku Plus ja helpotat el=E4m=E4=E4si.
> > http://www.mtv3.fi/luukku
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ...................................................................
> > > > > > Luukku Plus paketilla p=E4=E4set eroon tila- ja
> > turvallisuusongelmista.
> > > > > > Hanki Luukku Plus ja helpotat el=E4m=E4=E4si. http://www.mtv3.f=
i/luukku
> > > > > >
> > > > > >
> > > >
> > > >
> > > > ...................................................................
> > > > Luukku Plus paketilla p=E4=E4set eroon tila- ja turvallisuusongelmi=
sta.
> > > > Hanki Luukku Plus ja helpotat el=E4m=E4=E4si. http://www.mtv3.fi/lu=
ukku
> > > >
> > > >
> >
> >
> > ...................................................................
> > Luukku Plus paketilla p=E4=E4set eroon tila- ja turvallisuusongelmista.
> > Hanki Luukku Plus ja helpotat el=E4m=E4=E4si. http://www.mtv3.fi/luukku
> >
> >


...................................................................
Luukku Plus paketilla p=E4=E4set eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat el=E4m=E4=E4si. http://www.mtv3.fi/luukku