I am observing that in a single transaction while looking up distinct records the hibernate gets really slow. The reason is that because unique records are looked up and hibernate caches them and every new record that is looked up, the hibernates looks the item in the query, basically iterating through its cache list. This lookup time increases as hibernate cache builds up. I am talkign about ~ 1000 item look ups. My question is
1. Why does hibernate get slow with unique item lookup. What mechanism is it using to lookup the item in the cache?
2. While hibernate looks the item first in the cache before loading it from database, it DOES NOT call persistent objects hascode and equals method.Again how does it lookup item?
3. Is there any solution to to the slowness other than clearing the session cache every tome item is looked up?
The reason is that because unique records are looked up and hibernate caches them and every new record that is looked up, the hibernates looks the item in the query, basically iterating through its cache list. This lookup time increases as hibernate cache builds up. I am talkign about ~ 1000 item look ups. My question is
This should speed it up rather than slow it down. Looking a value up in the cache is considerably quicker than performing a database read, assuming there is a hit in the cache. Even if there is not a hit unless you have had your session open for a very long time (1000 doesn't sound like a big cache though) this should still be quick.
You use the term "lookup" - does this mean you are using a query (HQL or Criteria) or are you loading something into the session.
I am using HQL select statements with where clause . My records are unique and hence there is no hit in the cache. I am pretty much convinced that hibernate cache causes the slow down, because if I clear the cache after every select the next look ups inside the same session run faster. What I am not sure is how does hibernate compare the items in the cache, because I don't see hibernate calling persistent objects equals and hashcode method.
No my sessions are not long and there is nothing else going on in the session.
Thank you for your response.
You may be right, but even assuming Hibernate were doing something daft with object equality 1000 results is still not likely to be big enough to dramatically slow your application down. Hibernate doesn't need to use equals and hashcode to compare object identity, assuming you have an object loaded into the session with a particular primary key. If you ask for an obejct with that key Hibernate will spot this and return that object instance.
That aside if you are querying stuff via HQL Hibernate doesn't need to go back to the database after the objects are loaded. If you subequently call session.get for a returned object Hibernate will g oto the session cache and the database will not be touched. How did you obseerve this behaviour? Can you post some code?