I am suggesting to run a query in the em.flush() catch block. I haven't coded this because my stopgap solution seems to work fast enough so as to not bother, but if there were a lot of constraints to check for individually, one would not want to do a separate query to check each one every time there is an update, so putting these queries (constraint checks) in the em.flush() catch block would seem useful.
On the other hand, the code still wouldn't be able to detect that a constraint violation occurred simply because an exception was thrown because there could be other causes. I suppose one could make the assumption that a constraint violation may have occurred, and then do the constraint test queries in the catch block. If none fail, then the exception was caused by something else.
There's another problem that comes to mind. If you're updating a tree of objects at once, you really wouldn't have any idea what happened should a PersistenceException be thrown. Do you have any suggestions for how to handle that situation? This would seem to be a common situation.
I still think the spec should be enhanced to deal with this issue in the next release. Tell us the object and constraint that caused the exception.
[Message sent by forum member 'rickhoro' (rickhoro)]
http://forums.java.net/jive/thread.jspa?messageID=234318