Databases
StackOverflow2013
Postsdbo
POTransaction rollback in OSGi
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POTransaction rollback in OSGi
    primarykey
    data
    text
    <p>I have an OSGi bundle in which I declare a service and inject into it a transaction with blueprint:</p> <pre><code>&lt;bean id="MyServiceImpl" class="com.test.impl.MyServiceImpl"&gt; &lt;jpa:context property="em" unitname="mypu" /&gt; &lt;tx:transaction method="*" value="Required" /&gt; &lt;/bean&gt; &lt;service id="MyService" ref="MyServiceImpl" interface="com.test.api.MyService" /&gt; </code></pre> <p>In this service I have two methods each one of which is writing data in the database, something like the following:</p> <pre><code>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 } </code></pre> <p>My problems are the following:</p> <ol> <li>If I throw a runtime exception in the createParent method between <code>em.persist(parent);</code> and <code>createChild();</code> 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 <a href="http://aries.15396.n3.nabble.com/Will-any-exception-happened-will-rollback-the-declarative-transaction-td4026786.html" rel="nofollow">Aries mailing list</a> 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?</li> <li>If I throw a runtime exception in the createChild method (after <code>em.persist(child);</code>) 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?</li> <li>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.</li> <li>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.</li> </ol> <p>Can someone please explain the above behavior?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USChristina
    1. USChristina
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POTransaction rollback in OSGi
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POTransaction rollback in OSGi
      1. USMiTaes
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload