Greetings,

In my searches on google and here I have seen this problem discussed twice but no resolution was provided that I could find so I'm reposting...

I have the following table (simplified for example) used for xref:

ITEM1ID ITEM2ID TYPEID
---------- ---------- --------

1 1 56
1 2 56
2 2 56
1 3 56

ITEM1ID and ITEM2ID are the composite key.

It is used to manage many to many associations between ITEM1 and ITEM2. I have an Object that represents the table and I would like to retrieve all rows for a particular TYPEID. So I used the following:

Query q = hSession.createQuery("from XrefData x where x.typeID = :typeID");
q.setLong("typeID", 56);
list = q.list();

However the list returns the exact same XrefData Object 4 times (verified by outputting the list it is not an improper iteration). The data in the Object is from the first row. Looking at the DEBUG messages the actual result set is returning the 4 different rows. And I can see it returning the correct data for each row as it gets it from each column. But in the end the List from .list returns the same Object 4 times.

More DEBUG info:

- Hibernate runs the query and logs "processing result set"
- Hibernate returns the row info for the first row
- logs "result row: XrefData@d5c76e"
- logs "Initializing object from ResultSet: XrefData@d5c76e"
- logs "Hydrating entity: XrefData#XrefData@d5c76e"

It then starts processing the next 3 rows. But the last 3 log messages are not generated for the remaining 3 rows. Also only the composite key columns are returned in the "returning (value) as column (col)" log messages.

I don't know if Hibernate level 1 cache just considers them to be all the same Object based on an identifier of some kind.

Any help appreciated.

Thanks,

Derek

I found the error after more experimentation.

We have a superclass for all types of Data. The hashCode and equals method are overridden to check for equlity based on typeID. (for other reasons...again it's a bit more complex as I've simplified it for this example)

So I overrode hashCode and equals in the XrefData class to match the composite key used for the table and I now get 4 different Objects. It seems hibernate was indeed being smart with it's level 1 cache and our code was incorrect.