For the second transaction, lcte.setName("some value 2"),
I suggest the question should specify that the lcte entity instance is the
same entity instance in created before line 1.
If the lcte in the second transaction is referring to a new entity, then option 2 is correct.
About Question enthuware.oce-jpad.v6.2.351 :
Moderator: admin
-
- Posts: 358
- Joined: Fri Nov 29, 2013 8:26 pm
- Contact:
-
- Site Admin
- Posts: 10090
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-jpad.v6.2.351 :
The code is quite clear about which object lcte is pointing to at any point. It doesn't indicate any missing lines implicitly (using ...) or explicitly. So there should no confusion about it.
-Paul.
-Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 7
- Joined: Wed Jun 25, 2014 12:44 pm
- Contact:
Re: About Question enthuware.oce-jpad.v6.2.351 :
can this also be a possible answer if it is given as an option?
M1
M3
M2
M4
M1
M3
M1
M3
M2
M4
M1
M3
-
- Posts: 358
- Joined: Fri Nov 29, 2013 8:26 pm
- Contact:
Re: About Question enthuware.oce-jpad.v6.2.351 :
The reason why you think it may be :
m1 (the first persist)
m3
m2 (update the entity)
m4
m1 (merge the entity)
m3
As I tried something like that before, I have two different scenarios:
1. if the entity has not been in the DB yet, calling the merge will trigger the pre/post persist.
2. if the entity has been in the DB due to a previous commit from the previous transaction, calling merge will update the entity. In this case , the pre/post update will be called.
But in this case, the entity is updated by calling the setter method. This entity is still managed because the persistence context is extended by using the resource local transaction with the application managed entity manager as specified by the question. The merge does not do anything.
Actually, calling the merge is not even necessary. Also, according to spec 3.2.7.1 "If X is managed entity,the entity will be ignored by merge operation."
Therefore, when the second merge is called, the pre/post persist or pre/post update is not triggered.
m1 (the first persist)
m3
m2 (update the entity)
m4
m1 (merge the entity)
m3
As I tried something like that before, I have two different scenarios:
1. if the entity has not been in the DB yet, calling the merge will trigger the pre/post persist.
2. if the entity has been in the DB due to a previous commit from the previous transaction, calling merge will update the entity. In this case , the pre/post update will be called.
But in this case, the entity is updated by calling the setter method. This entity is still managed because the persistence context is extended by using the resource local transaction with the application managed entity manager as specified by the question. The merge does not do anything.
Actually, calling the merge is not even necessary. Also, according to spec 3.2.7.1 "If X is managed entity,the entity will be ignored by merge operation."
Therefore, when the second merge is called, the pre/post persist or pre/post update is not triggered.
-
- Posts: 7
- Joined: Wed Jun 25, 2014 12:44 pm
- Contact:
Re: About Question enthuware.oce-jpad.v6.2.351 :
thanks for the explanation.
Who is online
Users browsing this forum: No registered users and 11 guests