==> further investigations showed that this happens in EJB3-RC8 as well as EJB3-RC9 !!
- any ideas ?
according to the specification (Ejb-3_0-spec-persistence.pdf chapter 3.5.2) the behaviour of @PrePersist and @PreUpdate may be different.
in short words (trying to keep the meaning correct)
@PrePersist and @PreRemove are called before the EntityManger methods persist and remove are executed on the Entity. (leaving out details on merging here! -> thus your code shows "prepersist" before "procedd"
@PreUpdate is defined differently, though. It occurs before the database operation. The database operation is not exactly scheduled. It can occur due to a flush, or at the end of the transaction -> which is after the try clause
in your code -> so the ordering of the "preupdate" and "proceed" messages in the result output is correct, but not guaranteed.
but that means that you have NO chance to intercept a business-logic call from a client who is doing an update on an entity that has cascading enabled !!!
Assume 2 entities e.g. person [1:n] address. You have got a business-method that can be called with person as an attribute only, and the client changed a referenced address-object (remember cascade all is enabled !). So we get a call-back in the pre-update-Method of the address, but we will never know that in the interceptor of the business-logic call, due to the late update-callback (unfortunaltelly we can not use an entityManager in listener-callbacks, but we have also no chance doing this in an interceptor !!!)
In other words I would have to check weather any address-object has changed myself although I am using ejb3 that is doing these things anyhow ! So why am I using ejb3, if I have to reinvent the wheel ?
Thx for any feedback