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
