MyBatis, Spring and CMT

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

MyBatis, Spring and CMT

Hunter
Is anyone using MyBatis-Spring integration and Container Managed
Transactions? This question came up in a dev discussion and we
realized that we haven't tested anything other than Spring's
DataSourceTransactionManager.

I am pretty sure that if you get a container DataSource through JNDI,
there's no issue - just use that DataSource in a
DataSourceTransactionManager as usual.

If you are using container transactions, then you should use
JTATransactionManager. JTATransactionManager's tx lifecycle is mostly
managed by PlatformTransactionManager, just like DataSourceTxMgr. So,
I _think_ TX synchronization should still be activated and MyBatis
will work like normal.

Has anyone run MyBatis-Spring in a JEE server?
Can you verify that JTATransactionManager works correctly?

It would be great if we can get confirmation on a non-opensource
server like WebSphere or WebLogic before the next RC candidate (or
actual release).
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron

Hi Hunter. Finally I have tested it with glassfish and mysql. I did
two tests.

1- With <tx:jta-transaction-manager />

1- With EJB CMT. In this scenario there is no transaction manager
defined in spring. Commits & rollbacks are performed at EJB level.
Connections should be closed at MyBatis level.

The first test went OK. Sessions are reused properly. Connections are
commited and closed al the datasourceutils level. SqlSession is
commited at SqlSessionSynchronization. SpringManagedTransaction
receives the commit call but does not manage the transaction (no
commit no close)

The second test went partially wrong. As we thought
SpringTransactionManager tries to manage connections so it commits and
rollbacks and it should not. I set the transactionFactory to MyBatis
ManagedTransactionFactory and it worked as expected. No commit or
rollback, and it closes the connection.

    <bean id="sqlSessionFactory"
class="org.mybatis.spring.SqlSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="transactionFactoryClass"
value="org.apache.ibatis.transaction.managed.ManagedTransactionFactory" /
>
    </bean>

But I see an aditional problem here. MyBatis checks it SqlSession is
"dirty" (that means there is a uncommited update) and if it should
autocommit. Autocommit is read from connection and in my case it was
true when I execute if from a unit test but false when running in a
CMT.

  private boolean isCommitOrRollbackRequired(boolean force) {
    return (!autoCommit && dirty) || force;
  }

When autocommit is false and a insert/update/delete has been executed.
MyBatis will rollback the connection. If using
SpringManagedTransaction it will indeed rollback it. If using
ManagedTransaction it wont do nothing. So it will work but it is an
unexpected behaviour. Maybe this use case should be managed, commiting
or rolling back sqlsessions when spring transaction is not active.

Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron

Replying to myself. This behaviour I have described is in fact how
MyBatis behaves under a CMT environment. I mean, mybatis-spring does
not interfere.

So I should correct myself and say that mybatis-spring seems to work
OK in all situations.

All we have to do is documenting this case properly.

On 18 oct, 01:25, Eduardo <[hidden email]> wrote:

> Hi Hunter. Finally I have tested it with glassfish and mysql. I did
> two tests.
>
> 1- With <tx:jta-transaction-manager />
>
> 1- With EJB CMT. In this scenario there is no transaction manager
> defined in spring. Commits & rollbacks are performed at EJB level.
> Connections should be closed at MyBatis level.
>
> The first test went OK. Sessions are reused properly. Connections are
> commited and closed al the datasourceutils level. SqlSession is
> commited at SqlSessionSynchronization. SpringManagedTransaction
> receives the commit call but does not manage the transaction (no
> commit no close)
>
> The second test went partially wrong. As we thought
> SpringTransactionManager tries to manage connections so it commits and
> rollbacks and it should not. I set the transactionFactory to MyBatis
> ManagedTransactionFactory and it worked as expected. No commit or
> rollback, and it closes the connection.
>
>     <bean id="sqlSessionFactory"
> class="org.mybatis.spring.SqlSessionFactoryBean">
>         <property name="dataSource" ref="dataSource" />
>         <property name="transactionFactoryClass"
> value="org.apache.ibatis.transaction.managed.ManagedTransactionFactory" /
>
>     </bean>
>
> But I see an aditional problem here. MyBatis checks it SqlSession is
> "dirty" (that means there is a uncommited update) and if it should
> autocommit. Autocommit is read from connection and in my case it was
> true when I execute if from a unit test but false when running in a
> CMT.
>
>   private boolean isCommitOrRollbackRequired(boolean force) {
>     return (!autoCommit && dirty) || force;
>   }
>
> When autocommit is false and a insert/update/delete has been executed.
> MyBatis will rollback the connection. If using
> SpringManagedTransaction it will indeed rollback it. If using
> ManagedTransaction it wont do nothing. So it will work but it is an
> unexpected behaviour. Maybe this use case should be managed, commiting
> or rolling back sqlsessions when spring transaction is not active.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron

As promised here goes the results with WAS 7

1- With <tx:jta-transaction-manager /> OK

2- With EJB CMT. -> same result as in glassfish

    Finally I used oracle. In was, oracle datasource provides a
connection with autocommit set to true both with and without CMT. So
MyBatis never calls SpringManagedTransaction.rollback()

   Forcing the autocommit to false.
SpringManagedTransaction.rollback() is called and it results in a
SqlException (rollback is not allowed under global tx) but its ignored
by MyBatis (BaseExecutor.java)

  public void close(boolean forceRollback) {
    try {
      try {
        rollback(forceRollback);
      } finally {
        if (transaction != null) transaction.close();
      }
    } catch (SQLException e) {
      // Ignore.  There's nothing that can be done at this point.
    } finally {
      transaction = null;
      deferredLoads = null;
      localCache = null;
      batchResults = null;
      closed = true;
    }
  }

 A quick recap :)
- With CMT transaction. SpringManagedTransaction commits and
rollbacks, that produces an Exception but it is catched and ignored by
MyBatis.
  If ManagedTransactionFactory is used exceptions are avoided.
  MyBatis will call *Transaction.rollback() if datasource has
autocommit set to false and a insert/update/delete has been executed.

Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Hunter
Thanks Eduardo for running these tests!

I think the errors you are seeing are expected. Using
ManagedTransactionFactory as a workaround is not correct.

My understanding of Spring is that you should always use a JTA tx
manager if you are using CMT. JtaTransactionManager, through the
UserTransaction, will use the existing TX started by the container.
What we want to say in the doc is that if CMT is enabled, you should
always use JTA tx manager. Is that what you are thinking too?


On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:

> As promised here goes the results with WAS 7
>
> 1- With <tx:jta-transaction-manager /> OK
>
> 2- With EJB CMT. -> same result as in glassfish
>
>     Finally I used oracle. In was, oracle datasource provides a
> connection with autocommit set to true both with and without CMT. So
> MyBatis never calls SpringManagedTransaction.rollback()
>
>    Forcing the autocommit to false.
> SpringManagedTransaction.rollback() is called and it results in a
> SqlException (rollback is not allowed under global tx) but its ignored
> by MyBatis (BaseExecutor.java)
>
>   public void close(boolean forceRollback) {
>     try {
>       try {
>         rollback(forceRollback);
>       } finally {
>         if (transaction != null) transaction.close();
>       }
>     } catch (SQLException e) {
>       // Ignore.  There's nothing that can be done at this point.
>     } finally {
>       transaction = null;
>       deferredLoads = null;
>       localCache = null;
>       batchResults = null;
>       closed = true;
>     }
>   }
>
>  A quick recap :)
> - With CMT transaction. SpringManagedTransaction commits and
> rollbacks, that produces an Exception but it is catched and ignored by
> MyBatis.
>   If ManagedTransactionFactory is used exceptions are avoided.
>   MyBatis will call *Transaction.rollback() if datasource has
> autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Simone Tripodi
Thanks both for the *hard* work guys! and nice to see people committed
to the project :)

ABout the topic, AFAIK the ManagedTransactionFactory was designed to
face situations like these, from the manual:

"MANAGED – This configuration simply does almost nothing. It never
commits, or rolls back a connection. Instead, it lets the container
manage the full lifecycle of the transaction (e.g. Spring or a JEE
Application Server context). By default it does close the connection.
However, some containers don’t expect this, and thus if you need to
stop it from closing the connection, set the closeConnection property
to false."

So maybe we have to implement a serie of bridges form Containers
transaction managers and the MyBatis' ManagedTransactionFactory?

Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Oct 19, 2010 at 1:51 PM, Hunter <[hidden email]> wrote:

> Thanks Eduardo for running these tests!
>
> I think the errors you are seeing are expected. Using
> ManagedTransactionFactory as a workaround is not correct.
>
> My understanding of Spring is that you should always use a JTA tx
> manager if you are using CMT. JtaTransactionManager, through the
> UserTransaction, will use the existing TX started by the container.
> What we want to say in the doc is that if CMT is enabled, you should
> always use JTA tx manager. Is that what you are thinking too?
>
>
> On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>> As promised here goes the results with WAS 7
>>
>> 1- With <tx:jta-transaction-manager /> OK
>>
>> 2- With EJB CMT. -> same result as in glassfish
>>
>>     Finally I used oracle. In was, oracle datasource provides a
>> connection with autocommit set to true both with and without CMT. So
>> MyBatis never calls SpringManagedTransaction.rollback()
>>
>>    Forcing the autocommit to false.
>> SpringManagedTransaction.rollback() is called and it results in a
>> SqlException (rollback is not allowed under global tx) but its ignored
>> by MyBatis (BaseExecutor.java)
>>
>>   public void close(boolean forceRollback) {
>>     try {
>>       try {
>>         rollback(forceRollback);
>>       } finally {
>>         if (transaction != null) transaction.close();
>>       }
>>     } catch (SQLException e) {
>>       // Ignore.  There's nothing that can be done at this point.
>>     } finally {
>>       transaction = null;
>>       deferredLoads = null;
>>       localCache = null;
>>       batchResults = null;
>>       closed = true;
>>     }
>>   }
>>
>>  A quick recap :)
>> - With CMT transaction. SpringManagedTransaction commits and
>> rollbacks, that produces an Exception but it is catched and ignored by
>> MyBatis.
>>   If ManagedTransactionFactory is used exceptions are avoided.
>>   MyBatis will call *Transaction.rollback() if datasource has
>> autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
In reply to this post by Hunter

Not exactly Hunter. I am pretty sure that you cannot start a JTA
transaction in a EJB CMT. For using JTA, you should set the EJB to
BMT, otherwise I think it will fail. So when using CMT, Spring layer
should do simply nothing :)

I will try to test this on WAS tomorrow to confirm it.

On 19 oct, 13:51, Hunter <[hidden email]> wrote:

> Thanks Eduardo for running these tests!
>
> I think the errors you are seeing are expected. Using
> ManagedTransactionFactory as a workaround is not correct.
>
> My understanding of Spring is that you should always use a JTA tx
> manager if you are using CMT. JtaTransactionManager, through the
> UserTransaction, will use the existing TX started by the container.
> What we want to say in the doc is that if CMT is enabled, you should
> always use JTA tx manager. Is that what you are thinking too?
>
> On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
>
>
> > As promised here goes the results with WAS 7
>
> > 1- With <tx:jta-transaction-manager /> OK
>
> > 2- With EJB CMT. -> same result as in glassfish
>
> >     Finally I used oracle. In was, oracle datasource provides a
> > connection with autocommit set to true both with and without CMT. So
> > MyBatis never calls SpringManagedTransaction.rollback()
>
> >    Forcing the autocommit to false.
> > SpringManagedTransaction.rollback() is called and it results in a
> > SqlException (rollback is not allowed under global tx) but its ignored
> > by MyBatis (BaseExecutor.java)
>
> >   public void close(boolean forceRollback) {
> >     try {
> >       try {
> >         rollback(forceRollback);
> >       } finally {
> >         if (transaction != null) transaction.close();
> >       }
> >     } catch (SQLException e) {
> >       // Ignore.  There's nothing that can be done at this point.
> >     } finally {
> >       transaction = null;
> >       deferredLoads = null;
> >       localCache = null;
> >       batchResults = null;
> >       closed = true;
> >     }
> >   }
>
> >  A quick recap :)
> > - With CMT transaction. SpringManagedTransaction commits and
> > rollbacks, that produces an Exception but it is catched and ignored by
> > MyBatis.
> >   If ManagedTransactionFactory is used exceptions are avoided.
> >   MyBatis will call *Transaction.rollback() if datasource has
> > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
In reply to this post by Simone Tripodi

Yes Simo. You are right but current mybatis-spring has its own
TransactionFactory so MyBatis performs as a ManagedTransactionFactory
on connections handled by Spring and like a JdbcTransactionFactory on
connections not managed by Spring. The problem is that I think we
cannot know if we are under a CMT so we need some kind of external
config, like for example forcing ManagedTransactionFactory to be used.

On 19 oct, 14:35, Simone Tripodi <[hidden email]> wrote:

> Thanks both for the *hard* work guys! and nice to see people committed
> to the project :)
>
> ABout the topic, AFAIK the ManagedTransactionFactory was designed to
> face situations like these, from the manual:
>
> "MANAGED – This configuration simply does almost nothing. It never
> commits, or rolls back a connection. Instead, it lets the container
> manage the full lifecycle of the transaction (e.g. Spring or a JEE
> Application Server context). By default it does close the connection.
> However, some containers don’t expect this, and thus if you need to
> stop it from closing the connection, set the closeConnection property
> to false."
>
> So maybe we have to implement a serie of bridges form Containers
> transaction managers and the MyBatis' ManagedTransactionFactory?
>
> Simo
>
> http://people.apache.org/~simonetripodi/http://www.99soft.org/
>
>
>
> On Tue, Oct 19, 2010 at 1:51 PM, Hunter <[hidden email]> wrote:
> > Thanks Eduardo for running these tests!
>
> > I think the errors you are seeing are expected. Using
> > ManagedTransactionFactory as a workaround is not correct.
>
> > My understanding of Spring is that you should always use a JTA tx
> > manager if you are using CMT. JtaTransactionManager, through the
> > UserTransaction, will use the existing TX started by the container.
> > What we want to say in the doc is that if CMT is enabled, you should
> > always use JTA tx manager. Is that what you are thinking too?
>
> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
> >> As promised here goes the results with WAS 7
>
> >> 1- With <tx:jta-transaction-manager /> OK
>
> >> 2- With EJB CMT. -> same result as in glassfish
>
> >>     Finally I used oracle. In was, oracle datasource provides a
> >> connection with autocommit set to true both with and without CMT. So
> >> MyBatis never calls SpringManagedTransaction.rollback()
>
> >>    Forcing the autocommit to false.
> >> SpringManagedTransaction.rollback() is called and it results in a
> >> SqlException (rollback is not allowed under global tx) but its ignored
> >> by MyBatis (BaseExecutor.java)
>
> >>   public void close(boolean forceRollback) {
> >>     try {
> >>       try {
> >>         rollback(forceRollback);
> >>       } finally {
> >>         if (transaction != null) transaction.close();
> >>       }
> >>     } catch (SQLException e) {
> >>       // Ignore.  There's nothing that can be done at this point.
> >>     } finally {
> >>       transaction = null;
> >>       deferredLoads = null;
> >>       localCache = null;
> >>       batchResults = null;
> >>       closed = true;
> >>     }
> >>   }
>
> >>  A quick recap :)
> >> - With CMT transaction. SpringManagedTransaction commits and
> >> rollbacks, that produces an Exception but it is catched and ignored by
> >> MyBatis.
> >>   If ManagedTransactionFactory is used exceptions are avoided.
> >>   MyBatis will call *Transaction.rollback() if datasource has
> >> autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
In reply to this post by Eduardo Macarron

I have much to learn from you Hunter :)

It just worked with JtaTrasactionManager under WAS and CMT. The magic
seems to be in WebSphereUowTransactionManager that is able to know if
there is a current transaction running and knows what to do.

I still have chance to be right with glassfish. Lets try ;)

On 19 oct, 16:13, Eduardo <[hidden email]> wrote:

> Not exactly Hunter. I am pretty sure that you cannot start a JTA
> transaction in a EJB CMT. For using JTA, you should set the EJB to
> BMT, otherwise I think it will fail. So when using CMT, Spring layer
> should do simply nothing :)
>
> I will try to test this on WAS tomorrow to confirm it.
>
> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>
>
>
> > Thanks Eduardo for running these tests!
>
> > I think the errors you are seeing are expected. Using
> > ManagedTransactionFactory as a workaround is not correct.
>
> > My understanding of Spring is that you should always use a JTA tx
> > manager if you are using CMT. JtaTransactionManager, through the
> > UserTransaction, will use the existing TX started by the container.
> > What we want to say in the doc is that if CMT is enabled, you should
> > always use JTA tx manager. Is that what you are thinking too?
>
> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
> > > As promised here goes the results with WAS 7
>
> > > 1- With <tx:jta-transaction-manager /> OK
>
> > > 2- With EJB CMT. -> same result as in glassfish
>
> > >     Finally I used oracle. In was, oracle datasource provides a
> > > connection with autocommit set to true both with and without CMT. So
> > > MyBatis never calls SpringManagedTransaction.rollback()
>
> > >    Forcing the autocommit to false.
> > > SpringManagedTransaction.rollback() is called and it results in a
> > > SqlException (rollback is not allowed under global tx) but its ignored
> > > by MyBatis (BaseExecutor.java)
>
> > >   public void close(boolean forceRollback) {
> > >     try {
> > >       try {
> > >         rollback(forceRollback);
> > >       } finally {
> > >         if (transaction != null) transaction.close();
> > >       }
> > >     } catch (SQLException e) {
> > >       // Ignore.  There's nothing that can be done at this point.
> > >     } finally {
> > >       transaction = null;
> > >       deferredLoads = null;
> > >       localCache = null;
> > >       batchResults = null;
> > >       closed = true;
> > >     }
> > >   }
>
> > >  A quick recap :)
> > > - With CMT transaction. SpringManagedTransaction commits and
> > > rollbacks, that produces an Exception but it is catched and ignored by
> > > MyBatis.
> > >   If ManagedTransactionFactory is used exceptions are avoided.
> > >   MyBatis will call *Transaction.rollback() if datasource has
> > > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Simone Tripodi
Hi guys,
let's seriously think if it is the case to improve the transaction
design, the library should simplify developers' life, everybody
agrees?
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Oct 19, 2010 at 7:51 PM, Eduardo <[hidden email]> wrote:

>
> I have much to learn from you Hunter :)
>
> It just worked with JtaTrasactionManager under WAS and CMT. The magic
> seems to be in WebSphereUowTransactionManager that is able to know if
> there is a current transaction running and knows what to do.
>
> I still have chance to be right with glassfish. Lets try ;)
>
> On 19 oct, 16:13, Eduardo <[hidden email]> wrote:
>> Not exactly Hunter. I am pretty sure that you cannot start a JTA
>> transaction in a EJB CMT. For using JTA, you should set the EJB to
>> BMT, otherwise I think it will fail. So when using CMT, Spring layer
>> should do simply nothing :)
>>
>> I will try to test this on WAS tomorrow to confirm it.
>>
>> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>>
>>
>>
>> > Thanks Eduardo for running these tests!
>>
>> > I think the errors you are seeing are expected. Using
>> > ManagedTransactionFactory as a workaround is not correct.
>>
>> > My understanding of Spring is that you should always use a JTA tx
>> > manager if you are using CMT. JtaTransactionManager, through the
>> > UserTransaction, will use the existing TX started by the container.
>> > What we want to say in the doc is that if CMT is enabled, you should
>> > always use JTA tx manager. Is that what you are thinking too?
>>
>> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>>
>> > > As promised here goes the results with WAS 7
>>
>> > > 1- With <tx:jta-transaction-manager /> OK
>>
>> > > 2- With EJB CMT. -> same result as in glassfish
>>
>> > >     Finally I used oracle. In was, oracle datasource provides a
>> > > connection with autocommit set to true both with and without CMT. So
>> > > MyBatis never calls SpringManagedTransaction.rollback()
>>
>> > >    Forcing the autocommit to false.
>> > > SpringManagedTransaction.rollback() is called and it results in a
>> > > SqlException (rollback is not allowed under global tx) but its ignored
>> > > by MyBatis (BaseExecutor.java)
>>
>> > >   public void close(boolean forceRollback) {
>> > >     try {
>> > >       try {
>> > >         rollback(forceRollback);
>> > >       } finally {
>> > >         if (transaction != null) transaction.close();
>> > >       }
>> > >     } catch (SQLException e) {
>> > >       // Ignore.  There's nothing that can be done at this point.
>> > >     } finally {
>> > >       transaction = null;
>> > >       deferredLoads = null;
>> > >       localCache = null;
>> > >       batchResults = null;
>> > >       closed = true;
>> > >     }
>> > >   }
>>
>> > >  A quick recap :)
>> > > - With CMT transaction. SpringManagedTransaction commits and
>> > > rollbacks, that produces an Exception but it is catched and ignored by
>> > > MyBatis.
>> > >   If ManagedTransactionFactory is used exceptions are avoided.
>> > >   MyBatis will call *Transaction.rollback() if datasource has
>> > > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
Glassfish is disconcerting.

First of all, I simply tried to make an insert using plan jdbc and
perform a commit to be sure that glassfish will throw an exception for
trying to commit a local resource in a global transaction.. but it did
not. Global transaction seems to work fine, if there is no con.commit,
data is commited then ejb method finishes and it also rollbacks fine
with a RuntimeException.

Without JtaTransactionManager, SpringManagedTransaction receives a
rollback and it works, so no change is done on DB (remember that WAS
fired an exception so no rollback is done)

With JtaTransactionManager it fails, but it maybe is a Spring problem.

Caused by: java.lang.IllegalStateException: Operation not allowed.
        at
com.sun.enterprise.transaction.UserTransactionImpl.checkUserTransactionMethodAccess(UserTransactionImpl.java:
139)
        at
com.sun.enterprise.transaction.UserTransactionImpl.getStatus(UserTransactionImpl.java:
262)
        at
org.springframework.transaction.jta.JtaTransactionManager.isExistingTransaction(JtaTransactionManager.java:
795)
        at
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:
345)
        at
org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:
335)
        at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:
105)
        at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:
172)
        at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:
202)
        at $Proxy129.doSomeBusinessStuff(Unknown Source)
        at ejb.FooServiceEjb.execute(FooServiceEjb.java:56)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:
1056)
        at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:
1128)
        at
com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:
5292)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
        at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:
797)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
        at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:
157)
        at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:
139)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:
858)
        at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:
797)
        at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:
367)
        at
com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:
5264)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:
5252)
        at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:
190)
        ... 29 more


On 19 oct, 20:15, Simone Tripodi <[hidden email]> wrote:

> Hi guys,
> let's seriously think if it is the case to improve the transaction
> design, the library should simplify developers' life, everybody
> agrees?
> Simo
>
> http://people.apache.org/~simonetripodi/http://www.99soft.org/
>
>
>
> On Tue, Oct 19, 2010 at 7:51 PM, Eduardo <[hidden email]> wrote:
>
> > I have much to learn from you Hunter :)
>
> > It just worked with JtaTrasactionManager under WAS and CMT. The magic
> > seems to be in WebSphereUowTransactionManager that is able to know if
> > there is a current transaction running and knows what to do.
>
> > I still have chance to be right with glassfish. Lets try ;)
>
> > On 19 oct, 16:13, Eduardo <[hidden email]> wrote:
> >> Not exactly Hunter. I am pretty sure that you cannot start a JTA
> >> transaction in a EJB CMT. For using JTA, you should set the EJB to
> >> BMT, otherwise I think it will fail. So when using CMT, Spring layer
> >> should do simply nothing :)
>
> >> I will try to test this on WAS tomorrow to confirm it.
>
> >> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>
> >> > Thanks Eduardo for running these tests!
>
> >> > I think the errors you are seeing are expected. Using
> >> > ManagedTransactionFactory as a workaround is not correct.
>
> >> > My understanding of Spring is that you should always use a JTA tx
> >> > manager if you are using CMT. JtaTransactionManager, through the
> >> > UserTransaction, will use the existing TX started by the container.
> >> > What we want to say in the doc is that if CMT is enabled, you should
> >> > always use JTA tx manager. Is that what you are thinking too?
>
> >> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
> >> > > As promised here goes the results with WAS 7
>
> >> > > 1- With <tx:jta-transaction-manager /> OK
>
> >> > > 2- With EJB CMT. -> same result as in glassfish
>
> >> > >     Finally I used oracle. In was, oracle datasource provides a
> >> > > connection with autocommit set to true both with and without CMT. So
> >> > > MyBatis never calls SpringManagedTransaction.rollback()
>
> >> > >    Forcing the autocommit to false.
> >> > > SpringManagedTransaction.rollback() is called and it results in a
> >> > > SqlException (rollback is not allowed under global tx) but its ignored
> >> > > by MyBatis (BaseExecutor.java)
>
> >> > >   public void close(boolean forceRollback) {
> >> > >     try {
> >> > >       try {
> >> > >         rollback(forceRollback);
> >> > >       } finally {
> >> > >         if (transaction != null) transaction.close();
> >> > >       }
> >> > >     } catch (SQLException e) {
> >> > >       // Ignore.  There's nothing that can be done at this point.
> >> > >     } finally {
> >> > >       transaction = null;
> >> > >       deferredLoads = null;
> >> > >       localCache = null;
> >> > >       batchResults = null;
> >> > >       closed = true;
> >> > >     }
> >> > >   }
>
> >> > >  A quick recap :)
> >> > > - With CMT transaction. SpringManagedTransaction commits and
> >> > > rollbacks, that produces an Exception but it is catched and ignored by
> >> > > MyBatis.
> >> > >   If ManagedTransactionFactory is used exceptions are avoided.
> >> > >   MyBatis will call *Transaction.rollback() if datasource has
> >> > > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
In reply to this post by Simone Tripodi
Simo, I think this will just end up as a new chapter in the manual. I
seems that current code works fine on glasfish and webpshere. We just
should say how to configure mybatis-spring for EJB CMT environments.

On 19 oct, 20:15, Simone Tripodi <[hidden email]> wrote:

> Hi guys,
> let's seriously think if it is the case to improve the transaction
> design, the library should simplify developers' life, everybody
> agrees?
> Simo
>
> http://people.apache.org/~simonetripodi/http://www.99soft.org/
>
>
>
> On Tue, Oct 19, 2010 at 7:51 PM, Eduardo <[hidden email]> wrote:
>
> > I have much to learn from you Hunter :)
>
> > It just worked with JtaTrasactionManager under WAS and CMT. The magic
> > seems to be in WebSphereUowTransactionManager that is able to know if
> > there is a current transaction running and knows what to do.
>
> > I still have chance to be right with glassfish. Lets try ;)
>
> > On 19 oct, 16:13, Eduardo <[hidden email]> wrote:
> >> Not exactly Hunter. I am pretty sure that you cannot start a JTA
> >> transaction in a EJB CMT. For using JTA, you should set the EJB to
> >> BMT, otherwise I think it will fail. So when using CMT, Spring layer
> >> should do simply nothing :)
>
> >> I will try to test this on WAS tomorrow to confirm it.
>
> >> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>
> >> > Thanks Eduardo for running these tests!
>
> >> > I think the errors you are seeing are expected. Using
> >> > ManagedTransactionFactory as a workaround is not correct.
>
> >> > My understanding of Spring is that you should always use a JTA tx
> >> > manager if you are using CMT. JtaTransactionManager, through the
> >> > UserTransaction, will use the existing TX started by the container.
> >> > What we want to say in the doc is that if CMT is enabled, you should
> >> > always use JTA tx manager. Is that what you are thinking too?
>
> >> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
> >> > > As promised here goes the results with WAS 7
>
> >> > > 1- With <tx:jta-transaction-manager /> OK
>
> >> > > 2- With EJB CMT. -> same result as in glassfish
>
> >> > >     Finally I used oracle. In was, oracle datasource provides a
> >> > > connection with autocommit set to true both with and without CMT. So
> >> > > MyBatis never calls SpringManagedTransaction.rollback()
>
> >> > >    Forcing the autocommit to false.
> >> > > SpringManagedTransaction.rollback() is called and it results in a
> >> > > SqlException (rollback is not allowed under global tx) but its ignored
> >> > > by MyBatis (BaseExecutor.java)
>
> >> > >   public void close(boolean forceRollback) {
> >> > >     try {
> >> > >       try {
> >> > >         rollback(forceRollback);
> >> > >       } finally {
> >> > >         if (transaction != null) transaction.close();
> >> > >       }
> >> > >     } catch (SQLException e) {
> >> > >       // Ignore.  There's nothing that can be done at this point.
> >> > >     } finally {
> >> > >       transaction = null;
> >> > >       deferredLoads = null;
> >> > >       localCache = null;
> >> > >       batchResults = null;
> >> > >       closed = true;
> >> > >     }
> >> > >   }
>
> >> > >  A quick recap :)
> >> > > - With CMT transaction. SpringManagedTransaction commits and
> >> > > rollbacks, that produces an Exception but it is catched and ignored by
> >> > > MyBatis.
> >> > >   If ManagedTransactionFactory is used exceptions are avoided.
> >> > >   MyBatis will call *Transaction.rollback() if datasource has
> >> > > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Hunter
Eduardo, were you able to figure out that exception from Glassfish?
Does the below summary help or is something incompatible with Spring?

I see now that there are 4 use cases when running in a JEE container.
Notice that there's a difference between configuration and management.
You can configure and / or manage with Spring or the Container, in any
combination.

1) No transaction management - no configuration needed.
2) Spring transaction _configuration_
  a] Spring managed transactions - no extra configuration needed
  b] CMT - use JTA tx mgr
3) CMT managed and configured - must set ManagedTransactionFactory in
SqlSessionFactoryBean; configure tx using JEE container methods

Note that config 2a is just like using Spring for transactions outside
of the container. The container framework is being ignored.

I think the main use case for config 3 is if you have other container
managed resources that Spring can't manage, like a legacy app that
uses CMT.

On Oct 19, 5:01 pm, Eduardo <[hidden email]> wrote:

> Simo, I think this will just end up as a new chapter in the manual. I
> seems that current code works fine on glasfish and webpshere. We just
> should say how to configure mybatis-spring for EJB CMT environments.
>
> On 19 oct, 20:15, Simone Tripodi <[hidden email]> wrote:
>
>
>
> > Hi guys,
> > let's seriously think if it is the case to improve the transaction
> > design, the library should simplify developers' life, everybody
> > agrees?
> > Simo
>
> >http://people.apache.org/~simonetripodi/http://www.99soft.org/
>
> > On Tue, Oct 19, 2010 at 7:51 PM, Eduardo <[hidden email]> wrote:
>
> > > I have much to learn from you Hunter :)
>
> > > It just worked with JtaTrasactionManager under WAS and CMT. The magic
> > > seems to be in WebSphereUowTransactionManager that is able to know if
> > > there is a current transaction running and knows what to do.
>
> > > I still have chance to be right with glassfish. Lets try ;)
>
> > > On 19 oct, 16:13, Eduardo <[hidden email]> wrote:
> > >> Not exactly Hunter. I am pretty sure that you cannot start a JTA
> > >> transaction in a EJB CMT. For using JTA, you should set the EJB to
> > >> BMT, otherwise I think it will fail. So when using CMT, Spring layer
> > >> should do simply nothing :)
>
> > >> I will try to test this on WAS tomorrow to confirm it.
>
> > >> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>
> > >> > Thanks Eduardo for running these tests!
>
> > >> > I think the errors you are seeing are expected. Using
> > >> > ManagedTransactionFactory as a workaround is not correct.
>
> > >> > My understanding of Spring is that you should always use a JTA tx
> > >> > manager if you are using CMT. JtaTransactionManager, through the
> > >> > UserTransaction, will use the existing TX started by the container.
> > >> > What we want to say in the doc is that if CMT is enabled, you should
> > >> > always use JTA tx manager. Is that what you are thinking too?
>
> > >> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
> > >> > > As promised here goes the results with WAS 7
>
> > >> > > 1- With <tx:jta-transaction-manager /> OK
>
> > >> > > 2- With EJB CMT. -> same result as in glassfish
>
> > >> > >     Finally I used oracle. In was, oracle datasource provides a
> > >> > > connection with autocommit set to true both with and without CMT. So
> > >> > > MyBatis never calls SpringManagedTransaction.rollback()
>
> > >> > >    Forcing the autocommit to false.
> > >> > > SpringManagedTransaction.rollback() is called and it results in a
> > >> > > SqlException (rollback is not allowed under global tx) but its ignored
> > >> > > by MyBatis (BaseExecutor.java)
>
> > >> > >   public void close(boolean forceRollback) {
> > >> > >     try {
> > >> > >       try {
> > >> > >         rollback(forceRollback);
> > >> > >       } finally {
> > >> > >         if (transaction != null) transaction.close();
> > >> > >       }
> > >> > >     } catch (SQLException e) {
> > >> > >       // Ignore.  There's nothing that can be done at this point.
> > >> > >     } finally {
> > >> > >       transaction = null;
> > >> > >       deferredLoads = null;
> > >> > >       localCache = null;
> > >> > >       batchResults = null;
> > >> > >       closed = true;
> > >> > >     }
> > >> > >   }
>
> > >> > >  A quick recap :)
> > >> > > - With CMT transaction. SpringManagedTransaction commits and
> > >> > > rollbacks, that produces an Exception but it is catched and ignored by
> > >> > > MyBatis.
> > >> > >   If ManagedTransactionFactory is used exceptions are avoided.
> > >> > >   MyBatis will call *Transaction.rollback() if datasource has
> > >> > > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
Hi Hunter,

No I did not manage to solve that Glassfish problem. Don´t know if the
problem is in Glassfish or in Spring. It does not seem to be mybatis-
spring related because it also fails with JDBC. In fact,
JtaTransactionManager works fine if the EJB is setted as BMT.

I saw this same error in Glassfish forums, this post is dated 2008
http://old.nabble.com/Re:-JTS5041:-The-resource-manager-is-doing-work-outside-a-global-transaction-p18717503.html

I see that Spring is able to cooperate with vendors
TransactionManagers. In the case of Was transaction manager I can see
in Spring's code that it suspends/resumes WAS transactions so that
Springs "required new" works as expected.

So scenarios are 4 as you have said:
- no transaction (or handled by MyBatis) -> maybe this does not make
sense
- Spring transaction -> use Jta for global tx or
DatasourceTransactionManager for jdbc tx
- CMT + Spring transaction -> Use JtaTransactionManager (not always
works)
- CMT transaction -> use ManagedTransactionFactory

The last scenario will let you synchronize Spring transactions with
CMT. That is, resuming and supending a CMT transaction from Spring and
viceversa, suspending a Spring transaction from CMT. Seems that this
scenario not always works because TransactionManagers are nor part of
JEE (just UserTransaction is)

Scenario 4 can make sense in EJB architectures with Spring as a Dao
layer and MyBatis as data access layer. I know that in this case you
can just use mappers, but well, spring has some AOP extra capabilities
that can be useful and EJB 3.x can be injected using Spring ejb-
interceptors.

On 20 oct, 02:16, Hunter <[hidden email]> wrote:

> Eduardo, were you able to figure out that exception from Glassfish?
> Does the below summary help or is something incompatible with Spring?
>
> I see now that there are 4 use cases when running in a JEE container.
> Notice that there's a difference between configuration and management.
> You can configure and / or manage with Spring or the Container, in any
> combination.
>
> 1) No transaction management - no configuration needed.
> 2) Spring transaction _configuration_
>   a] Spring managed transactions - no extra configuration needed
>   b] CMT - use JTA tx mgr
> 3) CMT managed and configured - must set ManagedTransactionFactory in
> SqlSessionFactoryBean; configure tx using JEE container methods
>
> Note that config 2a is just like using Spring for transactions outside
> of the container. The container framework is being ignored.
>
> I think the main use case for config 3 is if you have other container
> managed resources that Spring can't manage, like a legacy app that
> uses CMT.
>
> On Oct 19, 5:01 pm, Eduardo <[hidden email]> wrote:
>
>
>
> > Simo, I think this will just end up as a new chapter in the manual. I
> > seems that current code works fine on glasfish and webpshere. We just
> > should say how to configure mybatis-spring for EJB CMT environments.
>
> > On 19 oct, 20:15, Simone Tripodi <[hidden email]> wrote:
>
> > > Hi guys,
> > > let's seriously think if it is the case to improve the transaction
> > > design, the library should simplify developers' life, everybody
> > > agrees?
> > > Simo
>
> > >http://people.apache.org/~simonetripodi/http://www.99soft.org/
>
> > > On Tue, Oct 19, 2010 at 7:51 PM, Eduardo <[hidden email]> wrote:
>
> > > > I have much to learn from you Hunter :)
>
> > > > It just worked with JtaTrasactionManager under WAS and CMT. The magic
> > > > seems to be in WebSphereUowTransactionManager that is able to know if
> > > > there is a current transaction running and knows what to do.
>
> > > > I still have chance to be right with glassfish. Lets try ;)
>
> > > > On 19 oct, 16:13, Eduardo <[hidden email]> wrote:
> > > >> Not exactly Hunter. I am pretty sure that you cannot start a JTA
> > > >> transaction in a EJB CMT. For using JTA, you should set the EJB to
> > > >> BMT, otherwise I think it will fail. So when using CMT, Spring layer
> > > >> should do simply nothing :)
>
> > > >> I will try to test this on WAS tomorrow to confirm it.
>
> > > >> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>
> > > >> > Thanks Eduardo for running these tests!
>
> > > >> > I think the errors you are seeing are expected. Using
> > > >> > ManagedTransactionFactory as a workaround is not correct.
>
> > > >> > My understanding of Spring is that you should always use a JTA tx
> > > >> > manager if you are using CMT. JtaTransactionManager, through the
> > > >> > UserTransaction, will use the existing TX started by the container.
> > > >> > What we want to say in the doc is that if CMT is enabled, you should
> > > >> > always use JTA tx manager. Is that what you are thinking too?
>
> > > >> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
> > > >> > > As promised here goes the results with WAS 7
>
> > > >> > > 1- With <tx:jta-transaction-manager /> OK
>
> > > >> > > 2- With EJB CMT. -> same result as in glassfish
>
> > > >> > >     Finally I used oracle. In was, oracle datasource provides a
> > > >> > > connection with autocommit set to true both with and without CMT. So
> > > >> > > MyBatis never calls SpringManagedTransaction.rollback()
>
> > > >> > >    Forcing the autocommit to false.
> > > >> > > SpringManagedTransaction.rollback() is called and it results in a
> > > >> > > SqlException (rollback is not allowed under global tx) but its ignored
> > > >> > > by MyBatis (BaseExecutor.java)
>
> > > >> > >   public void close(boolean forceRollback) {
> > > >> > >     try {
> > > >> > >       try {
> > > >> > >         rollback(forceRollback);
> > > >> > >       } finally {
> > > >> > >         if (transaction != null) transaction.close();
> > > >> > >       }
> > > >> > >     } catch (SQLException e) {
> > > >> > >       // Ignore.  There's nothing that can be done at this point.
> > > >> > >     } finally {
> > > >> > >       transaction = null;
> > > >> > >       deferredLoads = null;
> > > >> > >       localCache = null;
> > > >> > >       batchResults = null;
> > > >> > >       closed = true;
> > > >> > >     }
> > > >> > >   }
>
> > > >> > >  A quick recap :)
> > > >> > > - With CMT transaction. SpringManagedTransaction commits and
> > > >> > > rollbacks, that produces an Exception but it is catched and ignored by
> > > >> > > MyBatis.
> > > >> > >   If ManagedTransactionFactory is used exceptions are avoided.
> > > >> > >   MyBatis will call *Transaction.rollback() if datasource has
> > > >> > > autocommit set to false and a insert/update/delete has been executed.
Reply | Threaded
Open this post in threaded view
|

Re: MyBatis, Spring and CMT

Eduardo Macarron
Sorry when I said the "last scenario" I meant "the 3rd scenario".

On 20 oct, 18:24, Eduardo <[hidden email]> wrote:

> Hi Hunter,
>
> No I did not manage to solve that Glassfish problem. Don´t know if the
> problem is in Glassfish or in Spring. It does not seem to be mybatis-
> spring related because it also fails with JDBC. In fact,
> JtaTransactionManager works fine if the EJB is setted as BMT.
>
> I saw this same error in Glassfish forums, this post is dated 2008http://old.nabble.com/Re:-JTS5041:-The-resource-manager-is-doing-work...
>
> I see that Spring is able to cooperate with vendors
> TransactionManagers. In the case of Was transaction manager I can see
> in Spring's code that it suspends/resumes WAS transactions so that
> Springs "required new" works as expected.
>
> So scenarios are 4 as you have said:
> - no transaction (or handled by MyBatis) -> maybe this does not make
> sense
> - Spring transaction -> use Jta for global tx or
> DatasourceTransactionManager for jdbc tx
> - CMT + Spring transaction -> Use JtaTransactionManager (not always
> works)
> - CMT transaction -> use ManagedTransactionFactory
>
> The last scenario will let you synchronize Spring transactions with
> CMT. That is, resuming and supending a CMT transaction from Spring and
> viceversa, suspending a Spring transaction from CMT. Seems that this
> scenario not always works because TransactionManagers are nor part of
> JEE (just UserTransaction is)
>
> Scenario 4 can make sense in EJB architectures with Spring as a Dao
> layer and MyBatis as data access layer. I know that in this case you
> can just use mappers, but well, spring has some AOP extra capabilities
> that can be useful and EJB 3.x can be injected using Spring ejb-
> interceptors.
>
> On 20 oct, 02:16, Hunter <[hidden email]> wrote:
>
>
>
> > Eduardo, were you able to figure out that exception from Glassfish?
> > Does the below summary help or is something incompatible with Spring?
>
> > I see now that there are 4 use cases when running in a JEE container.
> > Notice that there's a difference between configuration and management.
> > You can configure and / or manage with Spring or the Container, in any
> > combination.
>
> > 1) No transaction management - no configuration needed.
> > 2) Spring transaction _configuration_
> >   a] Spring managed transactions - no extra configuration needed
> >   b] CMT - use JTA tx mgr
> > 3) CMT managed and configured - must set ManagedTransactionFactory in
> > SqlSessionFactoryBean; configure tx using JEE container methods
>
> > Note that config 2a is just like using Spring for transactions outside
> > of the container. The container framework is being ignored.
>
> > I think the main use case for config 3 is if you have other container
> > managed resources that Spring can't manage, like a legacy app that
> > uses CMT.
>
> > On Oct 19, 5:01 pm, Eduardo <[hidden email]> wrote:
>
> > > Simo, I think this will just end up as a new chapter in the manual. I
> > > seems that current code works fine on glasfish and webpshere. We just
> > > should say how to configure mybatis-spring for EJB CMT environments.
>
> > > On 19 oct, 20:15, Simone Tripodi <[hidden email]> wrote:
>
> > > > Hi guys,
> > > > let's seriously think if it is the case to improve the transaction
> > > > design, the library should simplify developers' life, everybody
> > > > agrees?
> > > > Simo
>
> > > >http://people.apache.org/~simonetripodi/http://www.99soft.org/
>
> > > > On Tue, Oct 19, 2010 at 7:51 PM, Eduardo <[hidden email]> wrote:
>
> > > > > I have much to learn from you Hunter :)
>
> > > > > It just worked with JtaTrasactionManager under WAS and CMT. The magic
> > > > > seems to be in WebSphereUowTransactionManager that is able to know if
> > > > > there is a current transaction running and knows what to do.
>
> > > > > I still have chance to be right with glassfish. Lets try ;)
>
> > > > > On 19 oct, 16:13, Eduardo <[hidden email]> wrote:
> > > > >> Not exactly Hunter. I am pretty sure that you cannot start a JTA
> > > > >> transaction in a EJB CMT. For using JTA, you should set the EJB to
> > > > >> BMT, otherwise I think it will fail. So when using CMT, Spring layer
> > > > >> should do simply nothing :)
>
> > > > >> I will try to test this on WAS tomorrow to confirm it.
>
> > > > >> On 19 oct, 13:51, Hunter <[hidden email]> wrote:
>
> > > > >> > Thanks Eduardo for running these tests!
>
> > > > >> > I think the errors you are seeing are expected. Using
> > > > >> > ManagedTransactionFactory as a workaround is not correct.
>
> > > > >> > My understanding of Spring is that you should always use a JTA tx
> > > > >> > manager if you are using CMT. JtaTransactionManager, through the
> > > > >> > UserTransaction, will use the existing TX started by the container.
> > > > >> > What we want to say in the doc is that if CMT is enabled, you should
> > > > >> > always use JTA tx manager. Is that what you are thinking too?
>
> > > > >> > On Oct 18, 8:09 am, Eduardo <[hidden email]> wrote:
>
> > > > >> > > As promised here goes the results with WAS 7
>
> > > > >> > > 1- With <tx:jta-transaction-manager /> OK
>
> > > > >> > > 2- With EJB CMT. -> same result as in glassfish
>
> > > > >> > >     Finally I used oracle. In was, oracle datasource provides a
> > > > >> > > connection with autocommit set to true both with and without CMT. So
> > > > >> > > MyBatis never calls SpringManagedTransaction.rollback()
>
> > > > >> > >    Forcing the autocommit to false.
> > > > >> > > SpringManagedTransaction.rollback() is called and it results in a
> > > > >> > > SqlException (rollback is not allowed under global tx) but its ignored
> > > > >> > > by MyBatis (BaseExecutor.java)
>
> > > > >> > >   public void close(boolean forceRollback) {
> > > > >> > >     try {
> > > > >> > >       try {
> > > > >> > >         rollback(forceRollback);
> > > > >> > >       } finally {
> > > > >> > >         if (transaction != null) transaction.close();
> > > > >> > >       }
> > > > >> > >     } catch (SQLException e) {
> > > > >> > >       // Ignore.  There's nothing that can be done at this point.
> > > > >> > >     } finally {
> > > > >> > >       transaction = null;
> > > > >> > >       deferredLoads = null;
> > > > >> > >       localCache = null;
> > > > >> > >       batchResults = null;
> > > > >> > >       closed = true;
> > > > >> > >     }
> > > > >> > >   }
>
> > > > >> > >  A quick recap :)
> > > > >> > > - With CMT transaction. SpringManagedTransaction commits and
> > > > >> > > rollbacks, that produces an Exception but it is catched and ignored by
> > > > >> > > MyBatis.
> > > > >> > >   If ManagedTransactionFactory is used exceptions are avoided.
> > > > >> > >   MyBatis will call *Transaction.rollback() if datasource has
> > > > >> > > autocommit set to false and a insert/update/delete has been executed.