I've been testing cache. I've noticed there is much less cache hits that I supposed it should be. Then I discovered the following behaviour:
DEBUG [Thread-0] (ReadWriteCache.java:68) - Cache lookup: 40201 DEBUG [Thread-0] (ReadWriteCache.java:78) - Cache hit: 40201 DEBUG [Thread-0] (ReadWriteCache.java:106) - Invalidating: 40201 DEBUG [Thread-0] (ReadWriteCache.java:178) - Releasing: 40201 DEBUG [Thread-0] (ReadWriteCache.java:68) - Cache lookup: 40201 DEBUG [Thread-0] (ReadWriteCache.java:87) - Cached item was locked: 40201 I've grepped only one record. Here is what it reads - first there is a cache hit, than item 40201 is updated, so it's invalidated in cache. Then it's released. At next lookup it appears locked. Why? When I looked at the code I thought that releasing is to put back the item into cache after it's commited. But it seems that it still remains locked after it's released. Is ot intentional behaviour? Or - is there any cache that saves the database lookup after record is updated? I mean my configuration is for single machine only - I don't need to bother that my database gets inconsistent. Another question - why records are flushed out the cache, efectively forcing database reread after they are updated in nonstrict-read-write. Is it also intentional? I think that after hibernate updates (successfully) database it should be assumed to have the most valid row copy. Flushing it out and forcing a reread is hard to understand for me, unless we assume that row is processed at db server causing potential insanity. I'm hibernated to 2.1.6. -- Mike ------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
