Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] re move() and a OneToMany mapping with CascadeType.PERSIST 
The problem is that the hashCode() of my entity changes during the transaction
resulting in that the entity is unequal to the backup clone.
(so the entity is changed and removed at the same time)
I am using the "business-Id" as the identity of an entity for equals() and hashCode().
As a consequence that the IndirectSet delegate cannot find the hashCode in the approriate hash bucket when calling Iterator.remove(). 

I have two questions:
1. Shouldn't IndirectSet.clear() rely on the delegate's clear() method instead of removing all elements using an iterator which fails in the above mentioned case. Currently IndirectSet seems to violate the Set interface contract which guarantees that clear() will remove all objects.
2. What is recommended/best way for implementing equals() / hashCode() in JPA/EclipseLink entities? 
I can see three options:
a) business-ID (all non-technical fields, without PK and FKs)
b) primary key
c) rely on Object.equals() / Object.hashCode()

Thank you and best regards,

Patric


Zitat von James Sutherland <jamesssss@xxxxxxxxx>:



I can't see anything wrong with the clear() method it uses an iterator to
remove all elements in the delegate.  The delegate should be empty after the
clear.  Are you seeing the delegate still having objects in it?


patric-7 wrote:



Calling clear() on the set should cause it to be removed as you will no
longer have a reference to the removed object.


Please have a look at IndirectSet.clear() in the source.
In my case, the delegate's clear() will not be invoked, so the
references are still there.
This causes that the non-empty Set will be traversed on commit when
changing the Set's parent hence undeleting the scheduled-for-removal
entities.


Zitat von James Sutherland <jamesssss@xxxxxxxxx>:



Calling clear() on the set should cause it to be removed as you will no
longer have a reference to the removed object.  Do you have a reference
from
another object?

I can't see how B could get re-persisted if you clear the reference to it
from A.  Are you sure there is no reference to be?  Perhaps put a
break-point in a prePersist event in B and check what is causing it to be
persisted.



patric-7 wrote:


I have no problem removing all references to an entity which has to be
removed.
What I am trying to point out is that EclipseLink behaves strangely in
a special case:

It makes a difference for EclipseLink if I remove the reference(s) by
setting the OneToMany-IndirectSet to null (this will work) or if I
call clear() on the IndirectSet (which won't work in case of the
cascade types exactly set to CascadeType.PERSIST, CascadeType.MERGE).


Zitat von James Sutherland <jamesssss@xxxxxxxxx>:



Before you remove and object you must ensure that you remove all
references
to it.  Otherwise you are corrupting your object model.  Normally you
would
get a constraint error if you tried to delete something that had
references,
but it depends on the constraint direction.

Before removing B you must remove it from A's collection of Bs (and all
other object that reference B).

The cascade persist in JPA is required by the JPA spec to re-persist
removed
objects (odd but true).  But not removing the reference to your removed
object is wrong and will corrupt your object model irregardless of the
JPA
issue, so you need to remove its references.

If you removed the cascade persist, the object would not get
re-persisted
(but you object would still be corrupt).

EclipseLink does provide some persistence unit properties that control
this
behavior,
"eclipselink.persistence-context.persist-on-commit"="false" - will
avoid
the
auto persist on commit
"eclipselink.persistence-context.commit-without-persist-rules"="true" -
may
resolve the issue


patric-7 wrote:


Your proposed workaround leads to the expected behavior - the entries
are
now
being removed.

Should I open a bug report?

Thank you and best regards,
Patric

Am 28.01.2011 19:02, schrieb Rohit Banga:

In case 1, can you try the following:


// initially a.getBs() will be a set containing one value
em.remove(B);
a.setAttr(somevalue);
a.setBs(null);

In this case I think B should be removed.
Can you please try this and post the behavior you observe?

Member Technical Staff
Oracle India Private Limited
91 80 41085685

----- Original Message -----
From: patric@xxxxxxxxxxx
To: eclipselink-users@xxxxxxxxxxx
Sent: Friday, January 28, 2011 7:28:02 PM GMT +05:30 Chennai,
Kolkata,
Mumbai, New Delhi
Subject: Re: [eclipselink-users] remove() and a OneToMany mapping
with
CascadeType.PERSIST

I'd like to add some additional information:

When adding the CascadeType.REFRESH to the OneToMany mapping,
the described "behavior" cannot be seen anymore:

    @OneToMany(mappedBy="gtrAnnTaxStmt_",
               cascade = { CascadeType.PERSIST, CascadeType.MERGE,
CascadeType.REFRESH })
    private Set  bSet_;


Best regards,
Patric

Zitat von patric@xxxxxxxxxxx:


Hello everyone,

I have a question regarding the importance of a remove() against a
cascade persist mapping.

Imagine a simple parent-child situation reflecting an 1:N
cardinality:

Entity class A is the parent, entity class B the child.
A defines a OneToMany mapping to B:

   @OneToMany(mappedBy="a_",
              cascade={CascadeType.PERSIST, CascadeType.MERGE} )
   private Set  bSet_;


In the following example one A instance references to exactly one B
instance.
Both are already persisted to the database and will be read after
the begin of the transaction.

Case #1:
When calling em.remove(B) and changing A followed by a commit, some
strange behavior can be seen:

B will not be removed.
It seems that the change to A causes that cascade persist will cause
a silent 'undeletion' of B.
(which happens during changeset calculation on commit)

Case #2:
When not changing A everything works expected and B will be removed.


My questions:

1. Are both cases intentional behavior?
I would expect that the explicit remove() should override the
implicit cascade persist in either cases.

2. Is there a a workaround that a remove() will be respect with
higher priority(beside removing the cascade on the mapping)?

Thank you and best regards,
Patric







-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James
Sutherland
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink
,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
Blog:  http://java-persistence-performance.blogspot.com/ Java
Persistence
Performance
--
View this message in context:
http://old.nabble.com/remove%28%29-and-a-OneToMany-mapping-with-CascadeType.PERSIST-tp30785713p30827278.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






_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users





-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance
--
View this message in context:
http://old.nabble.com/remove%28%29-and-a-OneToMany-mapping-with-CascadeType.PERSIST-tp30785713p30827819.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






_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users





-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance
--
View this message in context: http://old.nabble.com/remove%28%29-and-a-OneToMany-mapping-with-CascadeType.PERSIST-tp30785713p30884142.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

Back to the top