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.
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.
Jeff Butler
On 6/5/07, janne mattila <[EMAIL PROTECTED]> 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 != 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
