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.
|