-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: What can cause this behaviour? Duplicates in the database
PostPosted: Mon Apr 13, 2009 11:31 pm 
Regular
Regular

Joined: Wed Jan 21, 2009 8:41 pm
Posts: 54
Our model has the following relationship

A->B->C

where A can have many B's and B can have many C's

In our model the relationship from A->B is a set one-to-many
and the relationship from B->C is a set one-to-many

C's are optional

Now this code has been in production for many years but what I see today was that in the database instead of seeing something like

A->B->C1, C2, C3, C4

we're seeing

A->B->C1, C2, C2, C3, C4

C2 and C2 have the same natural key but physically different synthetic keys derived from sequences.

Also, our model uses a trigger on entity type C so because our code is currently written using session-per-operation we made use of select-before-update on entity type C.

So the question is. What set of circumstances can result in many C's appearing where with the exception of the physical primary key all other state is the same.

What is known that is the input records to create this data has only seen one instance of the record that creates C2. Normally if there are many C2's in the input set (ie. replaying the input data) the code will correctly update existing C2's and not create new ones.

I'm at a loss as to why we're seeing duplicates like this only today having had everything working without issue for many years.

We make use of ehcache and diskcaches and everything is eagerly loaded to avoid detatched objects.

We had a unique constraint on the physical keys B and C but not one that would prevent more than one instance of C being inserted where it differs by primary key but not natural key.

equals and hashCode seem to be implemented correctly for these entities in the model and again it's only today we've noticed the duplicate behaviour have had this code in production for over 2 years.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 13, 2009 11:43 pm 
Regular
Regular

Joined: Thu Sep 06, 2007 2:22 am
Posts: 108
Location: Noida,India
As you mentioned , equal and hashCode method are already there, so i think you are using java.util.list for relation B-->C. you you want to avoid duplicate, you java.util.Set for relation B-->C.

For Hibernate, two objects (of same entity) are same only if they have same identifier value (primary key). so if there are two Object of Type C, and all properties are same except primary key, then hibernate treat this object as different object.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.