About Question enthuware.oce-jpad.v6.2.422 :

Moderator: admin

Post Reply
ETS User

About Question enthuware.oce-jpad.v6.2.422 :

Post by ETS User »

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.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by admin »

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.
If you like our products and services, please help us by posting your review here.

cosminvacaroiu

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by cosminvacaroiu »

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

cosminvacaroiu

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by cosminvacaroiu »

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 ?

ramy6_1
Posts: 124
Joined: Wed Feb 12, 2014 2:44 am
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by ramy6_1 »

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

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by admin »

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?
If you like our products and services, please help us by posting your review here.

3uPh0riC
Posts: 2
Joined: Sun Dec 14, 2014 12:39 am
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by 3uPh0riC »

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?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by admin »

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.
If you like our products and services, please help us by posting your review here.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by himaiMinh »

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.

himaiMinh
Posts: 358
Joined: Fri Nov 29, 2013 8:26 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by himaiMinh »

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.

__JJ__
Posts: 125
Joined: Thu Jul 05, 2018 6:44 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by __JJ__ »

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.

__JJ__
Posts: 125
Joined: Thu Jul 05, 2018 6:44 pm
Contact:

Re: About Question enthuware.oce-jpad.v6.2.422 :

Post by __JJ__ »

What is strange is that remove followed by merge causes an IllegalArgumentException:

Code: Select all

Exception in thread "main" java.lang.IllegalArgumentException: org.hibernate.ObjectDeletedException: deleted instance passed to merge
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.

Post Reply

Who is online

Users browsing this forum: No registered users and 27 guests