This is a real pain to workaround since if a transaction is rolled back because of a database deadlock, entities with @GeneratedValue @Ids end up with bogus @Ids since the generated database values have been rolled back in the database, but not in the entities. Therefore, an automatic retry of the transaction will not work because the entities are now technically "detached" entities and em.persist() will fail. Even if full blown entity property rollback isn't implemented, it seems that at the very least @GeneratedValue @Id should be. Here is a possible workaround I can try: 1) Mark the entities in the entity graph which do not have @GeneratedValue @Id values set using a @PrePersist entity callback/listener. 2) Add an EJB3 Interceptor that wraps the CMT demarcation point. This could catch EJB3TransactionRolledbackException, traverse the entity graph in the EntityManager and unset the @Ids of the marked entities, then rethrow the EJB3TransactionRolledbackException. Does anyone have any better ideas? This solution seems rather dirty. Also, it may not even be possible to get a list of the currently managed entities from the EntityManager (I don't see any interface in EntityManager or org.hibernate.Session). Of course, it sure would be nice to have real entity bean property rollback semantics... ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958236#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...