I tried to perform very simple test of reading just whole table :

(UFO is very simple persistent class)
/* ... first I add few UFO records */
{ //all this few times (lets say 3)
UFO ufo = new UFO();
session.save(ufo);
}
//then I call few times read
{ //all this few times (lets say 3)
System.out.println("next read");
Criteria crit = session.createCriteria(UFO.class);
crit.setMaxResults(50);
crit.setCacheable(true);
crit.setTimeout( 2000);
List<UFO> cats = (List<UFO>)crit.list();
}
OK. all worked.

Suprise was: that in subsequent reads result was never taken from cache -> it always was "not up to date (as seen in logs) ". (and because of that there were redundant sql queries sent to my db)

I traced hibernate code and finally realised that all works when I close and open session after each query(!?).

This is simply because in:
StandardQueryCache.java there is a line
cacheable.add( new Long( session.getTimestamp() ) );
It means the timestamp is taken from openSession () !!!

I think this is general problem in hibernate when someone uses "longer"
sessions:
If You:
a) openSession();
b) add record to table (using session save)
c) make some subsequent reads (query)

You will never get upToDate cache results because after each query:
result is compared with last update time (b)
and then put into cache with time (a). (which of course does not make any sense as it is already later then (b)

I found two workarounds:
1. in my application open/close session after each read-> for me absolutely stupid.
2. in hibernate code change line to: cacheable.add( new Long( queryCache.nextTimestamp() ) );

Both works... but
as I am currently evaluating hibernate and do not know all ideas behind -> could someone explain this to me. Is this bug - or reasonable behaviour?

Hibernate version:
2.1 and 3.0 alpha

This is reasonable and expected, check for the accuracy of timestamps in your VM. Hibernate plays safe and your test does not respect real world concurrency.

accuracy of timestamps in my VM?
I do not really get the point.
My problem is that this is the first time I've seen in OR mapping that adding unnecesary closing/openning session could improve performance.

In terms of safeness this timestamp (I do not understand) in my opinion should be rather transaction wise not session wise?
Wouldn't it be better if this "session timestamp" was updated during beginTransaction() and transaction.commit()?
(maybe what I need is just a simple link to doc I couldn't find - about the way (ideas) hibernates manage "cache+transaction+timestamp" ).

I have noticed the same issue could some one please clarify why this is correct?

1 openSession() timestamp is set to say 0
2 performTransactedWork() lastupdated is set to say 1
3 doQuery hits database, timestamp in cache is set to 0
4 doQuery timestamp for cache is 0 which is older than lastupdated which is1
hits database, timestamp in cache is set to 0 :-(
5 doQuery...

/Konstantin