Hibernate version:
2.1.3 (tested with 2.1.7 as well)

I have a a named native sql query that returns about 20,000 records. The basic format of query is as follows

select
a.field1 as {cat.field1},
a.field2 as {cat.field2},
a.field3 as {cat.field3},
b.field1 as {hat.field1},
b.field2 as {hat.field2},
b.field3 as {hat.field3}
from
catTable a inner join hatTable b on a.field2 = b.field1

where every cat has one and only one hat and cat is also mapped to hat as cat.getHat().

If I check every result that is returned in the following manner
cat.getField2 == hat.getField1
and since caching is turned on this is the same as
cat.getField2 == cat.getHat().getField1

many of the results end up being incorrectly mapped. Has anyone ever experience a problem like this? Im happy to explain in more detail if this is unclear..

Thanks

Ok it appears that its the hash code thats at fault ....
For example,

int caseDiv = 11;
int caseYear = 3;
int caseNumber = 12694;

HashCodeBuilder hcb = new HashCodeBuilder();
long number = hcb.
append(new Integer(caseDiv)).
append(new Integer(caseYear)).
append(new Integer(caseNumber)).toHashCode();

System.out.println(number);

caseDiv = 11;
caseYear = 4;
caseNumber = 12657;
hcb = new HashCodeBuilder();
number = hcb.
append(new Integer(caseDiv)).
append(new Integer(caseYear)).
append(new Integer(caseNumber)).toHashCode();

System.out.println(number);

print out the same results ...

So Im guessing that the Session hashing function is colliding and not checking equals on the collision. Anyone know how this works?

So I gather that I have no control over the behavior of the Session cache, which is what is causing my collision problem???

I can make my composite id hash function more unique, but since its gotta be an integer there is no guarantee that there won't be a collision. Anyone run into this problem? Whats the solution constantly clearing the cache?

i dont get what your problem is....

The problem is that my composite-id class is auto-generated from hbm2java and the hashCode() method generates a bunch of collisions over my set of data. Whenever a collision occurs, Hibernate's Session-cache returns the previously loaded instance. However the cache is implemented though, it should be using equals to determine uniqueness and not hashCode().

Note: I have started looking through the Hibernate source, but I haven't gotten to the bottom of the problem yet.

Thanks for any insight and sorry it has taken me so many emails to get to a better description of the problem (I hope that this one is more clear).

hashcode is used inside hash based collections and very closely related to equals.

if the equals and hashcode collides to often well then you need to provide your own equals/hashcode impl.

In this case equals never collides, however hashCode() does so frequently. I can easily implement a new hashCode() with a very low collision rate, however there will be no gaurantee of zero collisions and when hashCode() does collide I can't have a situation where I am unknowlingly working with the wrong record.

I.e. If hashCode for PK1 and PK2 collide then I can end up with the record for PK1 (because of Session caching) even when I believe I have retrieved the record for PK2.

Thanks

huh ? that should not happen....collisions is only something that affects performance not correctness.

I agree ... Ill try to come up with a small test to duplicate.

Whew ... It was caused by a bug in hbm2java that was fixed in 2.1.2 of hibernate-extensions. Basically the equals() method generated in 2.1.1 started with

if (other == other) {
return true;

Thanks for patience.