Enthuware

In explanation "6. [...] entity is still a managed entity because it is still associated with the same entity manager".
This information isn't available in question. Merging operation even suggests otherwise. If entity is detached, exception is thrown on remove call.

The steps given in the question are all that you are allowed to consider and based on those steps there is no indication that the entity was detached. One can merge an entity even if it is not detached.

You can expect similar questions in the exam.

HTH,
Paul.

Yeah, it can be an extended or app managed EM.

What I'm not sure is why preRemove is called.
preRemove isn't necessary called when you call remove, but can be deferred until the commit. The callbacks happens in the order in which their methods were called ?

if i do: persist, remove: it will do prePersist, preRemove - postRemove. Or it might be preRemove, prePersist ?

Hello ,

I understand your explanation for the last option , but I still can't understand why PreRemove is called at this case ?

I think PreRemove is called when there will be a real change at the data base , like preUpdate and postUpdate.

Please explain

PreRemove will be called if you try to remove the entity. Where did you read that PreRemove will be called only when there will be a real change in the db?

I have the same question/concern about this question as some of these comments... I need to understand, when something like remove is called, does it immediately apply the pre-remove or does it wait until the transaction is committed to call pre/post remove. If its the latter, this question is wrong? Or might be wrong i guess, probably depending on specific provider implementation.

So is my understanding of it wrong, will it call @PreRemove immediately after calling the remove method even though the transaction is ongoing?

As per section 3.5.2 of JPA Specification, PreRemove will be invoked BEFORE the entity is removed (that is why it is called pre-), while the PostRemove method will be invoked after the database delete operation is performed.

So I am not sure what is the confusion. If you remove an entity, pre-remove will be invoked first whether there is a change in the DB or not. You might want to go through the above mentioned section of the specification for a clear understanding.

HTH,
Paul.

Hi, in the explanation in the last option, "However, in the given situation, an exception will be thrown because of the call to merge and so PreRemove will never be called."
I think it should be "PostRemove" will never be called.

One more note about some previous posts here. People may get confused about when PreRemove and PreUpdate are called.

PreUpdate is called before the entity's update is committed/flushed to the database and PostUpdate is called after the update is committed. Update can be done with or without a transaction. For example, this kind of update is not controlled by the entity manager and can be done with or without a transaction: "student.setName("New Name"). The entity manager's merge()/persist() is not used.These methods have to be used within a transaction if transactional scope container managed entity manager is used.

The specification allows the provider to decide whether Pre/post update are called in these two cases: 1. if a new entity is persisted and then modified 2. a managed entity is modified and then removed.
I believe the reason is that updating an entity (eg. changes like this: student.setName("...")) is not controlled by the entity manager unless it is a merge().

PreRemove is called when the em.remove(entityA) is called and PostRemove is called when entityA is removed from the database when the transaction is committed.
Remove is used within a transaction.

I hope this note can help people to clarify their confusion between the lifecycle callback methods of update and remove.

himaiMinh wrote: ↑

Mon Jul 03, 2017 2:23 pm

One more note about some previous posts here. People may get confused about when PreRemove and PreUpdate are called.

PreUpdate is called before the entity's update is committed/flushed to the database and PostUpdate is called after the update is committed...
PreRemove is called when the em.remove(entityA) is called and PostRemove is called when entityA is removed from the database when the transaction is committed.
Remove is used within a transaction.

I hope this note can help people to clarify their confusion between the lifecycle callback methods of update and remove.

No this is not true.

Firing of a PostPersist event does not indicate that the entity has committed successfully to the database because the transaction in which it as
persisted may be rolled back after the PostPersist event but before the transaction successfully commits....As with the PostPersist lifecycle event, the
postRemove event does not guarantee success. The enclosing transaction may still be rolled back....The PostUpdate callback occurs right after the
database update. The same potential for rollback exists after PostUpdate callbacks as with PostPersist and PostRemove.

The spec specifies the postXXX callback methods as occurring when XXX is invoked or upon a flush, but that's a flush, not a commit.

What is strange is that remove followed by merge causes an IllegalArgumentException:
but the remove itself seems not to be successful (even accounting for the fact that a "successful" remove could be rolled back) because the @PostRemove ELCM is not triggered before the merge failure. So delete->merge causes an exception where the deletion is blamed for the failure of the merge, but the deletion itself seems not to have completed pre-commit in the first place.

I have tested this with various SOPs and of course the annotated ELC methods.