Transaction rollback in OSGi

Question

I have an OSGi bundle in which I declare a service and inject into it a transaction 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 each one of which is writing data in the database, something like the following:

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
}

My problems are the following:

1. If I throw a runtime exception in the createParent method between em.persist(parent); and createChild(); the transaction rolls back (as I would expect) and parent is not persisted in the DB. However if at the same point I throw MyException (which is a checked exception) the transaction commits and parent is persisted. I saw in 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?
2. 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?
3. If I throw a runtime exception in the createParent method after the call to createChild I get the same behavior as in point 2 (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.
4. If in points 2 and 3 above the two methods are in different services then everything works as expected, ie. a runtime exception thrown in any of the methods rolls back the whole transaction.

Can someone please explain the above behavior?

Answer 1

After getting some help form the Aries mailing list it turns out the problem was in the datasource configuration and not in the blueprint configuration. 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.