[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Caching problem? when persisting a ManyToOne entity
|
I'm not sure I follow how the if statement in the code is involved in
the workaround other than to call merge on bin if part isn't in its
list. Please note that the entire method is commented out, so if you
did not intend the if statement to be executed and it is not included in
the workaround, you should not be showing it.
JPA does not manage bidirectional relationships for you. If you set one
side, you must also set the other. And those changes must be persisted
or merged. Owning a relationship is a way of setting which side of the
relationship controls the foreign key. IF you only set one side of a
bidirectional relationship, you will only see database updates when you
set the owning side. The spec states you must set both sides for the
cached objects to remain consistent with what is in the database. There
are ways to manage the cache, such as refreshing, invalidating or even
disabling the shared cache, but then you are potentially losing
performance over references that are usually easily handled in code.
In your situation, you are not adding part to a managed bin. Calling
persist on Part results in it being added to the context. But the
changes to a detached object can only be put into the context using
merge - you can resolve the issue by using merge on Part or Bin and
having the merge set to cascade over the relationship.
Best Regards,
Chris
On 03/09/2012 2:28 PM, Oldguy wrote:
as reply to Christopher:
You will note that the (only) if statements are in comments and should not
affect the test/problem nor the discussion here. As originally mentioned,
the comments were only included to show a workaround (general, thus the
if's)
As also originally mentioned, and demonstrated by the code, the Part *is*
added to the Bin's list.
A look at the code will show that addPartComplete IS the method being used.
Since the container is handling the transactions, it seems that bin is never
managed outside of the Facade file/class.
**NOTE**
Per your last sentence, I tried merging the bin and *not* persisting the
part, and all seems to work as originally expected, even if the Cascade is
removed from the @OneToMany in Bin, and even though the Part class is the
owning side of the relationship (isn't it??). This is surprising to me and
suggests that EclipseLink was implemented with the OneToMany side 'owning'
the relationship regardless of the spec's mention that use of mappedBy makes
the other side the owner. What am I missing/misunderstanding here?
*Restatement of the apparent issue: OneToMany side merge seems to take care
of 'related' ManyToOne side DB and cache changes, but ManyToOne side does
NOT seem to take care of OneToMany side cache (DB is not affected)
If efficient coding can not be done from the ManyToOne side using my
particular set of tools, I may just have to entirely rethink how I coded
this, to approach everything from the OneToMany side. Is there really no
choice here with EclipseLink? Is Hibernate better in this area? (ie
OneToMany side merge seems to take care of 'related' ManyToOne side DB and
cache, but ManyToOne side does NOT seem to take care of OneToMany side cache
(DB is not affected)
I would really appreciate it if someone can clear this(or me) up
definitively (no guesswork please).
Thank you in advance.
--
View this message in context: http://eclipse.1072660.n5.nabble.com/Caching-problem-when-persisting-a-ManyToOne-entity-tp154123p154136.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
