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