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
> >

Reply via email to