JTA not rolling back when deleting cascade fails

Question

Using: Glassfish 3.1.2, EclipseLink.

I have the following three-classes JPA model:

@Entity public class Customer implements Serializable {

@Id private Integer id;

@OneToOne(cascade={CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE}, orphanRemoval=true)
private Person person;

[...]

@Entity public class Person implements Serializable {

@Id private Integer id;

[...]

@Entity public class Request implements Serializable {

@Id private Integer id;

@ManyToOne private Person person;

I try to remove a customer with the following strategy (using CMT):

<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="MyPU" transaction-type="JTA">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
        <property name="eclipselink.ddl-generation" value="create-tables"/>
        <property name="eclipselink.ddl-generation.output-mode" value="database"/>

        <property name="eclipselink.logging.level" value="FINE"/>
        <property name="eclipselink.logging.parameters" value="true"/>
        <property name="eclipselink.logging.logger" value="DefaultLogger"/>                  
        <property name="eclipselink.logging.timestamp" value="true"/>
        <property name="eclipselink.logging.session" value="false"/>
        <property name="eclipselink.logging.thread" value="false"/>
    </properties>
</persistence-unit>

[...]

@PersistenceContext(unitName="MyPU")
private EntityManager entityManager;   

@Resource private SessionContext context;

[...]

public void delete(Entity object) {

    try{

        object = this.getEntityManager().merge(object);
        this.getEntityManager().remove(object);

    } catch (Exception e){

        this.context.setRollbackOnly();
    }
}

When the Customer object is attached to a Person object that is attached to a Request, the delete cascade of Person fails causing the transaction to rollback, but the Customer is deleted from the database. I receive the following error:

INFO: [EL Fine]: 2012-12-28 10:53:38.1--Connection(27132168)--DELETE FROM CUSTOMER WHERE (ID = ?)
bind => [97]
INFO: [EL Fine]: 2012-12-28 10:53:38.125--Connection(27132168)--DELETE FROM PERSON WHERE (ID = ?)
bind => [111]
INFO: [EL Fine]: 2012-12-28 10:53:38.126--SELECT 1
WARNING: DTX5014: Caught exception in beforeCompletion() callback:
Local Exception Stack:
INFO: [EL Warning]: 2012-12-28 10:53:38.127--Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: ERRO: atualização ou exclusão em tabela "person" viola restrição de chave estrangeira "fk_request_person_id" em "request"
Detalhe: Chave (id)=(111) ainda é referenciada pela tabela "request".
Error Code: 0
Call: DELETE FROM PERSON WHERE (ID = ?)
bind => [111]
Query: DeleteObjectQuery(111)
[...]
SEVERE: javax.ejb.EJBException: Transaction aborted
[...]

So, how can i cancel the customer removal when the cascade deletion fails?

Answer 1

There are two things that possible may go wrong here.

• The transaction boundaries are not correctly specified

Maybe due to this, your application server does not issue the BEGIN statement correctly. This would explain that Postgres has a problem, while Oracle does not (it implicitly starts a transaction). Make sure your service methods wear the correct annotations. If everything is fine, maybe

• There is a problem with your datasource.

Is it a JTA compatible datasource? Does it use the correct driver for Postgres? Please post your config so that we can check out.

I found an interesting link that may help you as well. It is about Postgres staying in autocommit mode (although when using Spring):

http://archives.postgresql.org/pgsql-jdbc/2007-07/msg00115.php