Expected behaviour OEMIV+Rollback expected, failed, states, wrong

amy

Is this a bug or an expected behavior?

With OEMIV I execute method1 which calls em.remove(object) which ends up in an Exception causing the tx rollback.
Within the same fromRequest I then call method2 which tries to find the instance that I tried to delete in method1 by using em.find(Class, Serializable). At this point a got a ObjectDeletedException which seems to be wrong as the removal failed and the tx got rollbacked.

I'm using the RC2 with Hibernate EM CR1.

the spec states that once an em throws an exception, it should be closed and a new one used for further operations.
This is what you should do since there is no guarantee from the spec on what the em behavior should be afterwards - I guess it might different from provider to provider.

Yes, I read this in the Spec but with the OEMIV filter and a JpaTransactionManager I really hoped that this should be transparent, that the ThreadLocal EM should be closed and populated with a new one.
Do you have any suggestion how this could be done transparently?

The OEMIV applies the same concept as with the Hibernate case  - and that is fail fast. In your case you'd like to get a new EM - however, it's not something that is going to work well.
Consider that you have a set of objects and half of them have been loaded with the initial EM (em1) and then you do a query, get an exception and automatically a new EM (em2) is placed on the thread. However, since the rest of your objects have been loaded through em1, they can't be lazy loaded since em1 has been closed. In this case a solution would be to reassociate the objects with em2.

Such behavior depends on the use case the dev is trying to solve and the solution is application-specific. To do such a thing transparently you could add an AOP interceptor to your classes so when an exception is caught you simply put back in a new em.
You could also wrap the real em in a proxy which automatically creates a new one if an exception is encountered - however, you'll have to distinguish between fatal and non-fatal exceptions. Note that the spec considers all exceptions to be fatal.

Thanks for your thoughts, I think I choose the pragmatic way and just ignore the Exception as non-recoverable which will force another request to fetch the data.