Hibernate version:
Hibernate 3.2.5 GA, EntityManager 3.3.1 GA
Mapping documents:
N/A
Code between sessionFactory.openSession() and session.close():
N/A
Full stack trace of any exception that occurs:
Exception in thread "main" javax.persistence.RollbackException: Error while commiting the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:71)
at operations.facade.CRUDService.execTransaction(CRUDService.java:54)
at operations.facade.CRUDService.delete(CRUDService.java:42)
at operations.client.SampleClient.accessDB(SampleClient.java:89)
at operations.client.SampleClient.main(SampleClient.java:38)
Caused by: org.hibernate.ObjectDeletedException: deleted entity passed to persist: [operations.domain.core.Employee#<null>]
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:90)
...
Name and version of the database you are using:
MySQL 5.0.5
The generated SQL (show_sql=true):
N/A
Debug level Hibernate log excerpt:
N/A

Hello,

my domain model has a simple class hierarchy: an Employee class annotated with *@Inheritance(strategy=InheritanceType.JOINED)* and a single subclass, Aeronaut.

The Airline class has an attribute that's a Collection of Employee. It includes both Employee and Aeronaut instances.

When I try to delete an Employee, everything's fine: I first remove the Employee from the Collection (which sets to NULL the Airline FK in the Employee table) and then I delete the record using EntityManager's remove().

When I try to delete an Aeronaut, however, my program fails with the above exception. I've repeated this test many times, so I'm sure this behavior is consistent.

I think this might be a bug that's just surfacing as JPA is too new and isn't being widely used yet.

I would really appreciate your help. Thanks so much,

Cristina

no, JPA is not new. Can you give some more details, there is probably something you're missing.

Hello,

I've managed to avoid the above exception by ensuring the Model Facade which wraps EntityManager's remove() method is declared as a *private static final* class variable in every client of the Facade's services. I don't know why such a change avoids the exception: besides being apparently unrelated to the problem I've described, it has been implemented as a response to another kind of exception.

This doesn't mean, however, that I'm now able to always delete subtype records: some records can be deleted, some can't, even though the delete transaction is reported as successful and no exceptions are thrown. If the undeletable records aren't inserted when the test DB is loaded, other records that previously could be deleted just won't be deleted anymore.

Cristina

There is probably something else going on. Hibernate has been rock solid for years wrt this behavior.