You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Christina Kaskoura <ch...@eurodyn.com> on 2013/09/30 08:36:48 UTC

Transaction rollback

I have an OSGi bundle with a service in which I inject transactional 
abilities with blueprint

|<bean id="MyServiceImpl"
           class="com.test.impl.MyServiceImpl">
     <jpa:context property="em"  unitname="mypu"  />
     <tx:transaction method="*"  value="Required"  />
</bean>
<service id="MyService"  ref="MyServiceImpl"  interface="com.test.api.MyService"  />|


In this service I have two methods both of which are writing data in the 
database:

|public  void  createParent()  throws  MyException  {
     Parent  parent=  new  Parent();
     ...  // Set parent fields
     em.persist(parent);
     createChild();
     // Checks that could throw MyException
}

public  void  createChild()  throws  MyException  {
     Child  child=  new  Child();
     ...  // Set child fields
     em.persist(child);
     // Checks that could throw MyException
}|


I notice however the following weird behavior:

 1. If I throw a runtime exception in the createChild method after
    |em.persist(child) |child is not persisted in the database, however
    parent is persisted, as if the two methods are running in two
    different transactions. Why is that? Shouldn't createChild join in
    the transaction started by createParent?
 2. If I throw a runtime exception in the createParent method after the
    call to createChild I get the same behavior as in point 1 (ie.
    parent is persisted and child is not persisted) which confuses me
    even more since even if I assume that createChild starts a new
    transaction then this should not get rolled back when an exception
    is thrown in createParent.

I also posted this question on stackoverflow 
(http://stackoverflow.com/questions/19031360/transaction-rollback-in-osgi) 
where I got the suggestion that perhaps there is a bug causing this 
behavior. Is this the case or am I not getting something in the way 
transactions are configured? Additionally, I saw in old messages of the 
Aries mailing list that a declared (checked) exception in a blueprint 
declarative transaction does not trigger a rollback. Is there a way to 
configure this behavior and specify that I want my exception to rollback 
the transaction when thrown? If not, what is the recommended approach to 
rolling back a transaction without throwing a runtime exception?

Thank you,
Christina




Re: Transaction rollback

Posted by John W Ross <jw...@us.ibm.com>.
The source for org.apache.aries.transaction.TxInterceptorImpl.
postCallWithException (in the org.apache.aries.transaction.blueprint
project) suggests the answer is no. It will only rollback the transaction
if the thrown exception is a RuntimeException or an Error.

In your stackoverflow post [1], you referenced a fairly recent note on this
mailing list [2] that suggests the blueprint transaction support is
intended to follow the same rules in EJB. This area is admittedly a bit
outside my comfort zone, and I may be misinterpreting, but it looks like
EJB allows developers to specify that a transaction be rolled back on a
checked exception using the @java.ejb.ApplicationException(rollback=true)
annotation. I see no equivalent in blueprint transactions. I don't know if
this is intentional, an oversight, or something that was left for the
future. Perhaps someone more familiar with the history of blueprint can
answer. In the meantime, you may wish to consider opening a JIRA [3] if
this is important to you.

John

[1]
http://stackoverflow.com/questions/19031360/transaction-rollback-in-osgi

[2]
http://aries.15396.n3.nabble.com/Will-any-exception-happened-will-rollback-the-declarative-transaction-td4026786.html

[3] https://issues.apache.org/jira/browse/ARIES

>
> Re: Transaction rollback
>
> Thank you John, you are absolutely right. I also tested with the
> Aries Blog sample which was working for me as well and after some
> digging it turned out that my datasource was not configured
> correctly. Although I was using MysqlXADataSource as a driver class
> the datasource service was registered as a javax.sql.DataSource
> instead of javax.sql.XADataSource which is what was messing up my
> transactions.
>
> Does anyone have an answer to my other question as well? Is there
> any way to trigger a transaction rollback when throwing checked
> exceptions or is my only option getting a reference to the
> TransactionManager and beginning/committing my transactions manually
> if I want to do that?
>
> Thank you,
> Christina
>
>
> On 01/10/2013 18:40, John W Ross wrote:
> I was unable to reproduce the behavior your describing on the latest
> code using the JPA piece of the Aries Blog sample (http://
> aries.apache.org/modules/samples/blog-sample.html).
>
> I modified BlogPersistenceServiceImpl so that the createAuthor
> method calls the createBlogPost method. The author is persisted
> before the call to createBlogPost. CreateBlogPost persists the new
> post then throws a runtime exception. Both methods are on the
> service interface and covered by <tx:transaction method="*"
> value="Required" />. Nothing was persisted as a result of the
> runtime exception.
>
> Maybe compare your project with the blog sample and note any differences?
>
> John
>
> >
> > Re: Transaction rollback
> >
> > I tried that but I am getting the exact same behavior, both with my
> > initial blueprint configuration and even if I specify in blueprint
> > for MyServiceImpl that a transaction should only be injected in the
> > createParent method.
> >
> > Christina
> >
> >
> > On 30/09/2013 16:49, John W Ross wrote:
> > Can you try creating a private doCreateChild() method on
> > MyServiceImpl that does everything createChild() does then have both
> > createParent() and createChild() call it? Does that work as you
> would expect?
> >
> > John
> >
> > >
> > > Re: Transaction rollback
> > >
> > > I have a listener service which listens to the bundle started event
> > > and in the handleEvent method calls the createParent() method.
> > > MyService is injected in the listener with blueprint:
> >
> > >     <bean id="BundleListener"
> > >           class="com.test.impl.listener.BundleListener">
> > >           <property name="myService" ref="MyServiceImpl"/>
> > >     </bean>
> > >     <service id="BundleListenerService" ref="BundleListener"
> > >              interface="org.osgi.service.event.EventHandler">
> > >         <service-properties>
> > >             <entry key="event.topics" value="org/osgi/framework/
> > > BundleEvent/STARTED"/>
> > >         </service-properties>
> > >     </service>
> > >
> > > I get the same behavior whether I inject a transaction in
> > > BundleListener or not.
> > >
> > > Regards,
> > > Christina
> > >
> > > On 30/09/2013 09:53, Tom Leung wrote:
> > > Where you starts calling the methods createParent() and createChild
()?
> > >
> > > Have you created  a client that get the reference of MyServiceImpl
> > > bean and then calls createParent() or createChild()?
> > >
> > > Please states the calling sequences clearly, so we can get what
> > > happened in your program.
> > >
> > > Best Rgds,
> > >
> > > Tom
> > >
> > >
> > >
> > > From: Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com]
> > > Sent: Monday, September 30, 2013 2:37 PM
> > > To: user@aries.apache.org
> > > Subject: Transaction rollback
> > >
> > > I have an OSGi bundle with a service in which I inject transactional
> > > abilities with blueprint
> > > <bean id="MyServiceImpl"
> > >           class="com.test.impl.MyServiceImpl">
> > >     <jpa:context property="em" unitname="mypu" />
> > >     <tx:transaction method="*" value="Required" />
> > > </bean>
> > > <service id="MyService" ref="MyServiceImpl"
> > > interface="com.test.api.MyService" />
> > >
> > > In this service I have two methods both of which are writing data in
> > > the database:
> > > public void createParent() throws MyException {
> > >     Parent parent = new Parent();
> > >     ... // Set parent fields
> > >     em.persist(parent);
> > >     createChild();
> > >     // Checks that could throw MyException
> > > }
> > >
> > > public void createChild() throws MyException {
> > >     Child child = new Child();
> > >     ... // Set child fields
> > >     em.persist(child);
> > >     // Checks that could throw MyException
> > > }
> > >
> > > I notice however the following weird behavior:
> > > 1. If I throw a runtime exception in the createChild method after
> > > em.persist(child) child is not persisted in the database, however
> > > parent is persisted, as if the two methods are running in two
> > > different transactions. Why is that? Shouldn't createChild join in
> > > the transaction started by createParent?
> > > 2. If I throw a runtime exception in the createParent method after
> > > the call to createChild I get the same behavior as in point 1 (ie.
> > > parent is persisted and child is not persisted) which confuses me
> > > even more since even if I assume that createChild starts a new
> > > transaction then this should not get rolled back when an exception
> > > is thrown in createParent.
> > > I also posted this question on stackoverflow (http://
> > > stackoverflow.com/questions/19031360/transaction-rollback-in-osgi)
> > > where I got the suggestion that perhaps there is a bug causing this
> > > behavior. Is this the case or am I not getting something in the way
> > > transactions are configured? Additionally, I saw in old messages of
> > > the Aries mailing list that a declared (checked) exception in a
> > > blueprint declarative transaction does not trigger a rollback. Is
> > > there a way to configure this behavior and specify that I want my
> > > exception to rollback the transaction when thrown? If not, what is
> > > the recommended approach to rolling back a transaction without
> > > throwing a runtime exception?
> > > Thank you,
> > > Christina
> > >

Re: Transaction rollback

Posted by Christina Kaskoura <ch...@eurodyn.com>.
Thank you John, you are absolutely right. I also tested with the Aries 
Blog sample which was working for me as well and after some digging it 
turned out that my datasource was not configured correctly. Although I 
was using MysqlXADataSource as a driver class the datasource service was 
registered as a javax.sql.DataSource instead of javax.sql.XADataSource 
which is what was messing up my transactions.

Does anyone have an answer to my other question as well? Is there any 
way to trigger a transaction rollback when throwing checked exceptions 
or is my only option getting a reference to the TransactionManager and 
beginning/committing my transactions manually if I want to do that?

Thank you,
Christina


On 01/10/2013 18:40, John W Ross wrote:
>
> I was unable to reproduce the behavior your describing on the latest 
> code using the JPA piece of the Aries Blog sample 
> (http://aries.apache.org/modules/samples/blog-sample.html).
>
> I modified BlogPersistenceServiceImpl so that the createAuthor method 
> calls the createBlogPost method. The author is persisted before the 
> call to createBlogPost. CreateBlogPost persists the new post then 
> throws a runtime exception. Both methods are on the service interface 
> and covered by <tx:transaction method="*" value="Required" />. Nothing 
> was persisted as a result of the runtime exception.
>
> Maybe compare your project with the blog sample and note any differences?
>
> John
>
> >
> > Re: Transaction rollback
> >
> > I tried that but I am getting the exact same behavior, both with my
> > initial blueprint configuration and even if I specify in blueprint
> > for MyServiceImpl that a transaction should only be injected in the
> > createParent method.
> >
> > Christina
> >
> >
> > On 30/09/2013 16:49, John W Ross wrote:
> > Can you try creating a private doCreateChild() method on
> > MyServiceImpl that does everything createChild() does then have both
> > createParent() and createChild() call it? Does that work as you 
> would expect?
> >
> > John
> >
> > >
> > > Re: Transaction rollback
> > >
> > > I have a listener service which listens to the bundle started event
> > > and in the handleEvent method calls the createParent() method.
> > > MyService is injected in the listener with blueprint:
> >
> > >     <bean id="BundleListener"
> > > class="com.test.impl.listener.BundleListener">
> > >           <property name="myService" ref="MyServiceImpl"/>
> > >     </bean>
> > >     <service id="BundleListenerService" ref="BundleListener"
> > >  interface="org.osgi.service.event.EventHandler">
> > >         <service-properties>
> > >             <entry key="event.topics" value="org/osgi/framework/
> > > BundleEvent/STARTED"/>
> > >         </service-properties>
> > >     </service>
> > >
> > > I get the same behavior whether I inject a transaction in
> > > BundleListener or not.
> > >
> > > Regards,
> > > Christina
> > >
> > > On 30/09/2013 09:53, Tom Leung wrote:
> > > Where you starts calling the methods createParent() and createChild()?
> > >
> > > Have you created  a client that get the reference of MyServiceImpl
> > > bean and then calls createParent() or createChild()?
> > >
> > > Please states the calling sequences clearly, so we can get what
> > > happened in your program.
> > >
> > > Best Rgds,
> > >
> > > Tom
> > >
> > >
> > >
> > > From: Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com]
> > > Sent: Monday, September 30, 2013 2:37 PM
> > > To: user@aries.apache.org
> > > Subject: Transaction rollback
> > >
> > > I have an OSGi bundle with a service in which I inject transactional
> > > abilities with blueprint
> > > <bean id="MyServiceImpl"
> > >           class="com.test.impl.MyServiceImpl">
> > >     <jpa:context property="em" unitname="mypu" />
> > >     <tx:transaction method="*" value="Required" />
> > > </bean>
> > > <service id="MyService" ref="MyServiceImpl"
> > > interface="com.test.api.MyService" />
> > >
> > > In this service I have two methods both of which are writing data in
> > > the database:
> > > public void createParent() throws MyException {
> > >     Parent parent = new Parent();
> > >     ... // Set parent fields
> > >     em.persist(parent);
> > >     createChild();
> > >     // Checks that could throw MyException
> > > }
> > >
> > > public void createChild() throws MyException {
> > >     Child child = new Child();
> > >     ... // Set child fields
> > >     em.persist(child);
> > >     // Checks that could throw MyException
> > > }
> > >
> > > I notice however the following weird behavior:
> > > 1. If I throw a runtime exception in the createChild method after
> > > em.persist(child) child is not persisted in the database, however
> > > parent is persisted, as if the two methods are running in two
> > > different transactions. Why is that? Shouldn't createChild join in
> > > the transaction started by createParent?
> > > 2. If I throw a runtime exception in the createParent method after
> > > the call to createChild I get the same behavior as in point 1 (ie.
> > > parent is persisted and child is not persisted) which confuses me
> > > even more since even if I assume that createChild starts a new
> > > transaction then this should not get rolled back when an exception
> > > is thrown in createParent.
> > > I also posted this question on stackoverflow (http://
> > > stackoverflow.com/questions/19031360/transaction-rollback-in-osgi)
> > > where I got the suggestion that perhaps there is a bug causing this
> > > behavior. Is this the case or am I not getting something in the way
> > > transactions are configured? Additionally, I saw in old messages of
> > > the Aries mailing list that a declared (checked) exception in a
> > > blueprint declarative transaction does not trigger a rollback. Is
> > > there a way to configure this behavior and specify that I want my
> > > exception to rollback the transaction when thrown? If not, what is
> > > the recommended approach to rolling back a transaction without
> > > throwing a runtime exception?
> > > Thank you,
> > > Christina
> > >
>


Re: Transaction rollback

Posted by John W Ross <jw...@us.ibm.com>.
I was unable to reproduce the behavior your describing on the latest code
using the JPA piece of the Aries Blog sample (
http://aries.apache.org/modules/samples/blog-sample.html).

I modified BlogPersistenceServiceImpl so that the createAuthor method calls
the createBlogPost method. The author is persisted before the call to
createBlogPost. CreateBlogPost persists the new post then throws a runtime
exception. Both methods are on the service interface and covered by
<tx:transaction method="*" value="Required" />. Nothing was persisted as a
result of the runtime exception.

Maybe compare your project with the blog sample and note any differences?

John

>
> Re: Transaction rollback
>
> I tried that but I am getting the exact same behavior, both with my
> initial blueprint configuration and even if I specify in blueprint
> for MyServiceImpl that a transaction should only be injected in the
> createParent method.
>
> Christina
>
>
> On 30/09/2013 16:49, John W Ross wrote:
> Can you try creating a private doCreateChild() method on
> MyServiceImpl that does everything createChild() does then have both
> createParent() and createChild() call it? Does that work as you would
expect?
>
> John
>
> >
> > Re: Transaction rollback
> >
> > I have a listener service which listens to the bundle started event
> > and in the handleEvent method calls the createParent() method.
> > MyService is injected in the listener with blueprint:
>
> >     <bean id="BundleListener"
> >           class="com.test.impl.listener.BundleListener">
> >           <property name="myService" ref="MyServiceImpl"/>
> >     </bean>
> >     <service id="BundleListenerService" ref="BundleListener"
> >              interface="org.osgi.service.event.EventHandler">
> >         <service-properties>
> >             <entry key="event.topics" value="org/osgi/framework/
> > BundleEvent/STARTED"/>
> >         </service-properties>
> >     </service>
> >
> > I get the same behavior whether I inject a transaction in
> > BundleListener or not.
> >
> > Regards,
> > Christina
> >
> > On 30/09/2013 09:53, Tom Leung wrote:
> > Where you starts calling the methods createParent() and createChild()?
> >
> > Have you created  a client that get the reference of MyServiceImpl
> > bean and then calls createParent() or createChild()?
> >
> > Please states the calling sequences clearly, so we can get what
> > happened in your program.
> >
> > Best Rgds,
> >
> > Tom
> >
> >
> >
> > From: Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com]
> > Sent: Monday, September 30, 2013 2:37 PM
> > To: user@aries.apache.org
> > Subject: Transaction rollback
> >
> > I have an OSGi bundle with a service in which I inject transactional
> > abilities with blueprint
> > <bean id="MyServiceImpl"
> >           class="com.test.impl.MyServiceImpl">
> >     <jpa:context property="em" unitname="mypu" />
> >     <tx:transaction method="*" value="Required" />
> > </bean>
> > <service id="MyService" ref="MyServiceImpl"
> > interface="com.test.api.MyService" />
> >
> > In this service I have two methods both of which are writing data in
> > the database:
> > public void createParent() throws MyException {
> >     Parent parent = new Parent();
> >     ... // Set parent fields
> >     em.persist(parent);
> >     createChild();
> >     // Checks that could throw MyException
> > }
> >
> > public void createChild() throws MyException {
> >     Child child = new Child();
> >     ... // Set child fields
> >     em.persist(child);
> >     // Checks that could throw MyException
> > }
> >
> > I notice however the following weird behavior:
> > 1. If I throw a runtime exception in the createChild method after
> > em.persist(child) child is not persisted in the database, however
> > parent is persisted, as if the two methods are running in two
> > different transactions. Why is that? Shouldn't createChild join in
> > the transaction started by createParent?
> > 2. If I throw a runtime exception in the createParent method after
> > the call to createChild I get the same behavior as in point 1 (ie.
> > parent is persisted and child is not persisted) which confuses me
> > even more since even if I assume that createChild starts a new
> > transaction then this should not get rolled back when an exception
> > is thrown in createParent.
> > I also posted this question on stackoverflow (http://
> > stackoverflow.com/questions/19031360/transaction-rollback-in-osgi)
> > where I got the suggestion that perhaps there is a bug causing this
> > behavior. Is this the case or am I not getting something in the way
> > transactions are configured? Additionally, I saw in old messages of
> > the Aries mailing list that a declared (checked) exception in a
> > blueprint declarative transaction does not trigger a rollback. Is
> > there a way to configure this behavior and specify that I want my
> > exception to rollback the transaction when thrown? If not, what is
> > the recommended approach to rolling back a transaction without
> > throwing a runtime exception?
> > Thank you,
> > Christina
> >

Re: Transaction rollback

Posted by Christina Kaskoura <ch...@eurodyn.com>.
I tried that but I am getting the exact same behavior, both with my 
initial blueprint configuration and even if I specify in blueprint for 
MyServiceImpl that a transaction should only be injected in the 
createParent method.

Christina


On 30/09/2013 16:49, John W Ross wrote:
>
> Can you try creating a private doCreateChild() method on MyServiceImpl 
> that does everything createChild() does then have both createParent() 
> and createChild() call it? Does that work as you would expect?
>
> John
>
> >
> > Re: Transaction rollback
> >
> > I have a listener service which listens to the bundle started event
> > and in the handleEvent method calls the createParent() method.
> > MyService is injected in the listener with blueprint:
>
> >     <bean id="BundleListener"
> > class="com.test.impl.listener.BundleListener">
> >           <property name="myService" ref="MyServiceImpl"/>
> >     </bean>
> >     <service id="BundleListenerService" ref="BundleListener"
> >  interface="org.osgi.service.event.EventHandler">
> >         <service-properties>
> >             <entry key="event.topics" value="org/osgi/framework/
> > BundleEvent/STARTED"/>
> >         </service-properties>
> >     </service>
> >
> > I get the same behavior whether I inject a transaction in
> > BundleListener or not.
> >
> > Regards,
> > Christina
> >
> > On 30/09/2013 09:53, Tom Leung wrote:
> > Where you starts calling the methods createParent() and createChild()?
> >
> > Have you created  a client that get the reference of MyServiceImpl
> > bean and then calls createParent() or createChild()?
> >
> > Please states the calling sequences clearly, so we can get what
> > happened in your program.
> >
> > Best Rgds,
> >
> > Tom
> >
> >
> >
> > From: Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com]
> > Sent: Monday, September 30, 2013 2:37 PM
> > To: user@aries.apache.org
> > Subject: Transaction rollback
> >
> > I have an OSGi bundle with a service in which I inject transactional
> > abilities with blueprint
> > <bean id="MyServiceImpl"
> > class="com.test.impl.MyServiceImpl">
> >     <jpa:context property="em" unitname="mypu" />
> >     <tx:transaction method="*" value="Required" />
> > </bean>
> > <service id="MyService" ref="MyServiceImpl"
> > interface="com.test.api.MyService" />
> >
> > In this service I have two methods both of which are writing data in
> > the database:
> > public void createParent() throws MyException {
> >     Parent parent = new Parent();
> >     ... // Set parent fields
> >     em.persist(parent);
> >     createChild();
> >     // Checks that could throw MyException
> > }
> >
> > public void createChild() throws MyException {
> >     Child child = new Child();
> >     ... // Set child fields
> >     em.persist(child);
> >     // Checks that could throw MyException
> > }
> >
> > I notice however the following weird behavior:
> > 1. If I throw a runtime exception in the createChild method after
> > em.persist(child) child is not persisted in the database, however
> > parent is persisted, as if the two methods are running in two
> > different transactions. Why is that? Shouldn't createChild join in
> > the transaction started by createParent?
> > 2. If I throw a runtime exception in the createParent method after
> > the call to createChild I get the same behavior as in point 1 (ie.
> > parent is persisted and child is not persisted) which confuses me
> > even more since even if I assume that createChild starts a new
> > transaction then this should not get rolled back when an exception
> > is thrown in createParent.
> > I also posted this question on stackoverflow (http://
> > stackoverflow.com/questions/19031360/transaction-rollback-in-osgi)
> > where I got the suggestion that perhaps there is a bug causing this
> > behavior. Is this the case or am I not getting something in the way
> > transactions are configured? Additionally, I saw in old messages of
> > the Aries mailing list that a declared (checked) exception in a
> > blueprint declarative transaction does not trigger a rollback. Is
> > there a way to configure this behavior and specify that I want my
> > exception to rollback the transaction when thrown? If not, what is
> > the recommended approach to rolling back a transaction without
> > throwing a runtime exception?
> > Thank you,
> > Christina
> >
>


Re: Transaction rollback

Posted by John W Ross <jw...@us.ibm.com>.
Can you try creating a private doCreateChild() method on MyServiceImpl that
does everything createChild() does then have both createParent() and
createChild() call it? Does that work as you would expect?

John

>
> Re: Transaction rollback
>
> I have a listener service which listens to the bundle started event
> and in the handleEvent method calls the createParent() method.
> MyService is injected in the listener with blueprint:

>     <bean id="BundleListener"
>           class="com.test.impl.listener.BundleListener">
>           <property name="myService" ref="MyServiceImpl"/>
>     </bean>
>     <service id="BundleListenerService" ref="BundleListener"
>              interface="org.osgi.service.event.EventHandler">
>         <service-properties>
>             <entry key="event.topics" value="org/osgi/framework/
> BundleEvent/STARTED"/>
>         </service-properties>
>     </service>
>
> I get the same behavior whether I inject a transaction in
> BundleListener or not.
>
> Regards,
> Christina
>
> On 30/09/2013 09:53, Tom Leung wrote:
> Where you starts calling the methods createParent() and createChild()?
>
> Have you created  a client that get the reference of MyServiceImpl
> bean and then calls createParent() or createChild()?
>
> Please states the calling sequences clearly, so we can get what
> happened in your program.
>
> Best Rgds,
>
> Tom
>
>
>
> From: Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com]
> Sent: Monday, September 30, 2013 2:37 PM
> To: user@aries.apache.org
> Subject: Transaction rollback
>
> I have an OSGi bundle with a service in which I inject transactional
> abilities with blueprint
> <bean id="MyServiceImpl"
>           class="com.test.impl.MyServiceImpl">
>     <jpa:context property="em" unitname="mypu" />
>     <tx:transaction method="*" value="Required" />
> </bean>
> <service id="MyService" ref="MyServiceImpl"
> interface="com.test.api.MyService" />
>
> In this service I have two methods both of which are writing data in
> the database:
> public void createParent() throws MyException {
>     Parent parent = new Parent();
>     ... // Set parent fields
>     em.persist(parent);
>     createChild();
>     // Checks that could throw MyException
> }
>
> public void createChild() throws MyException {
>     Child child = new Child();
>     ... // Set child fields
>     em.persist(child);
>     // Checks that could throw MyException
> }
>
> I notice however the following weird behavior:
> 1. If I throw a runtime exception in the createChild method after
> em.persist(child) child is not persisted in the database, however
> parent is persisted, as if the two methods are running in two
> different transactions. Why is that? Shouldn't createChild join in
> the transaction started by createParent?
> 2. If I throw a runtime exception in the createParent method after
> the call to createChild I get the same behavior as in point 1 (ie.
> parent is persisted and child is not persisted) which confuses me
> even more since even if I assume that createChild starts a new
> transaction then this should not get rolled back when an exception
> is thrown in createParent.
> I also posted this question on stackoverflow (http://
> stackoverflow.com/questions/19031360/transaction-rollback-in-osgi)
> where I got the suggestion that perhaps there is a bug causing this
> behavior. Is this the case or am I not getting something in the way
> transactions are configured? Additionally, I saw in old messages of
> the Aries mailing list that a declared (checked) exception in a
> blueprint declarative transaction does not trigger a rollback. Is
> there a way to configure this behavior and specify that I want my
> exception to rollback the transaction when thrown? If not, what is
> the recommended approach to rolling back a transaction without
> throwing a runtime exception?
> Thank you,
> Christina
>

Re: Transaction rollback

Posted by Christina Kaskoura <ch...@eurodyn.com>.
I have a listener service which listens to the bundle started event and 
in the handleEvent method calls the createParent() method. MyService is 
injected in the listener with blueprint:

     <bean id="BundleListener"

           class="com.test.impl.listener.BundleListener">

           <property name="myService" ref="MyServiceImpl"/>

     </bean>

     <service id="BundleListenerService" ref="BundleListener"

              interface="org.osgi.service.event.EventHandler">

         <service-properties>

             <entry key="event.topics" value="org/osgi/framework/BundleEvent/STARTED"/>

         </service-properties>

     </service>


I get the same behavior whether I inject a transaction in BundleListener 
or not.

Regards,
Christina

On 30/09/2013 09:53, Tom Leung wrote:
>
> Where you starts calling the methods createParent() and createChild()?
>
> Have you created  a client that get the reference of MyServiceImpl 
> bean and then calls createParent() or createChild()?
>
> Please states the calling sequences clearly, so we can get what 
> happened in your program.
>
> Best Rgds,
>
> Tom
>
> *From:*Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com]
> *Sent:* Monday, September 30, 2013 2:37 PM
> *To:* user@aries.apache.org
> *Subject:* Transaction rollback
>
> I have an OSGi bundle with a service in which I inject transactional 
> abilities with blueprint
>
> <bean id="MyServiceImpl"
>            class="com.test.impl.MyServiceImpl">
>      <jpa:context property="em"  unitname="mypu"  />
>      <tx:transaction method="*"  value="Required"  />
> </bean>
> <service id="MyService"  ref="MyServiceImpl"  interface="com.test.api.MyService"  />
>
>
> In this service I have two methods both of which are writing data in 
> the database:
>
> public  void  createParent()  throws  MyException  {
>      Parent  parent=  new  Parent();
>      ...  // Set parent fields
>      em.persist(parent);
>      createChild();
>      // Checks that could throw MyException
> }
>   
> public  void  createChild()  throws  MyException  {
>      Child  child=  new  Child();
>      ...  // Set child fields
>      em.persist(child);
>      // Checks that could throw MyException
> }
>
>
> I notice however the following weird behavior:
>
>  1. If I throw a runtime exception in the createChild method after
>     |em.persist(child) |child is not persisted in the database,
>     however parent is persisted, as if the two methods are running in
>     two different transactions. Why is that? Shouldn't createChild
>     join in the transaction started by createParent?
>  2. If I throw a runtime exception in the createParent method after
>     the call to createChild I get the same behavior as in point 1 (ie.
>     parent is persisted and child is not persisted) which confuses me
>     even more since even if I assume that createChild starts a new
>     transaction then this should not get rolled back when an exception
>     is thrown in createParent.
>
> I also posted this question on stackoverflow 
> (http://stackoverflow.com/questions/19031360/transaction-rollback-in-osgi) 
> where I got the suggestion that perhaps there is a bug causing this 
> behavior. Is this the case or am I not getting something in the way 
> transactions are configured? Additionally, I saw in old messages of 
> the Aries mailing list that a declared (checked) exception in a 
> blueprint declarative transaction does not trigger a rollback. Is 
> there a way to configure this behavior and specify that I want my 
> exception to rollback the transaction when thrown? If not, what is the 
> recommended approach to rolling back a transaction without throwing a 
> runtime exception?
>
> Thank you,
> Christina
>


RE: Transaction rollback

Posted by Tom Leung <to...@netage.com.hk>.
Where you starts calling the methods createParent() and createChild()?

 

Have you created  a client that get the reference of MyServiceImpl bean and
then calls createParent() or createChild()?

 

Please states the calling sequences clearly, so we can get what happened in
your program.

 

Best Rgds,

 

Tom

 

 

 

From: Christina Kaskoura [mailto:christina.kaskoura@eurodyn.com] 
Sent: Monday, September 30, 2013 2:37 PM
To: user@aries.apache.org
Subject: Transaction rollback

 

I have an OSGi bundle with a service in which I inject transactional
abilities with blueprint

<bean id="MyServiceImpl"
          class="com.test.impl.MyServiceImpl">
    <jpa:context property="em" unitname="mypu" />
    <tx:transaction method="*" value="Required" />
</bean>
<service id="MyService" ref="MyServiceImpl"
interface="com.test.api.MyService" />


In this service I have two methods both of which are writing data in the
database:

public void createParent() throws MyException {
    Parent parent = new Parent();
    ... // Set parent fields
    em.persist(parent);
    createChild();
    // Checks that could throw MyException
}
 
public void createChild() throws MyException {
    Child child = new Child();
    ... // Set child fields
    em.persist(child);
    // Checks that could throw MyException
}


I notice however the following weird behavior:

1.	If I throw a runtime exception in the createChild method after
em.persist(child) child is not persisted in the database, however parent is
persisted, as if the two methods are running in two different transactions.
Why is that? Shouldn't createChild join in the transaction started by
createParent?
2.	If I throw a runtime exception in the createParent method after the
call to createChild I get the same behavior as in point 1 (ie. parent is
persisted and child is not persisted) which confuses me even more since even
if I assume that createChild starts a new transaction then this should not
get rolled back when an exception is thrown in createParent.

I also posted this question on stackoverflow
(http://stackoverflow.com/questions/19031360/transaction-rollback-in-osgi)
where I got the suggestion that perhaps there is a bug causing this
behavior. Is this the case or am I not getting something in the way
transactions are configured? Additionally, I saw in old messages of the
Aries mailing list that a declared (checked) exception in a blueprint
declarative transaction does not trigger a rollback. Is there a way to
configure this behavior and specify that I want my exception to rollback the
transaction when thrown? If not, what is the recommended approach to rolling
back a transaction without throwing a runtime exception?

Thank you,
Christina