ConstraintViolationException no transaction rollback

[miguelz]

I'm using:

Seam 2.2.0 GA
Tomcat 6.0.18
Mysql 5.1 with InnoDB

-> Seam Transaction Management and POJOs used:

in components.xml
<transaction:entity-transaction entity-manager="#{entityManager}"/>

Using EntityHome components in a seam-gen generated CRUD Example with two entities in a parent-child relation (without cascade delete) and FlushType.Manual, as expected, I get a Hibernate ConstraintViolationException (caused by the corresponding Mysql-Exception) when I remove a parent instance with existing child instances.

My problem is, that there seems no way to recover cleanly from this exception.

The transaction does not get rolled back and the locks keep existing in Mysql-InnoDB causing further Timeout, LockExceptions etc...

Even if I handle the exception and destroy the conversation in pages.xml (with debug=false in components.xml and JSF/Facelets-Debug disabled in web.xml) like this:

<exception class="org.hibernate.exception.ConstraintViolationException">
        <end-conversation before-redirect="false"/>
        <redirect view-id="/error.xhtml">
            <message severity="warn">MySQLIntegrityConstraintViolationException</message>
        </redirect>
</exception>

the transaction is still alive and holds the locks:

---TRANSACTION 0 55373, ACTIVE 24 sec, OS thread id 3520
17 lock struct(s), heap size 1024, 17 row lock(s), undo log entries 5
MySQL thread id 42, query id 4014 localhost 127.0.0.1 ...

It seems that the transaction doesn't get rolled back and closed on every arbitrary non-catched runtime-exception as stated in the documentation ?!

Any comments?

Miguel

[miguelz]

P.S.

I also tried:

<end-conversation before-redirect="true"/>

[miguelz]

I discovered some new facts:

The above mentioned stale transactions occur with:

<h:commandButton
id="delete"
value="Delete"
immediate="true"
action="#{exampleHome.remove}"
rendered="#{exampleHome.managed}"/>

But when I remove the

immediate=true

line, then everything seems to work like expected.

My conclusion:

The RollbackInterceptor and/or TransactionInterceptor might not be applied/work well when immediate JSF execution (directly after the Apply Request Values phase) is used.

Any seam-transaction expert here?