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:[email protected]] > > > Sent: Monday, September 30, 2013 2:37 PM > > > To: [email protected] > > > 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 > > >
