I'm seeing the following unexpected behavior:

Class "Test" is declared with <cache usage="read-write" /> and 2nd level cache is enabled and query cache is enabled

1. Open session; load Test with ID 1 (NH issues SELECT statement, as expected); Close session
2. Open session; load Test with ID 1 (No database trip, as expected); Close session
3. Open session, load Test with ID 1 (No database trip, as expected); Change property of Test, Flush session (NH issues UPDATE statement, as expected); Close session
4. Open session; load Test with ID 1 (NH issues SELECT statement!); Close session

My question is why does NH issue another select statement in step 4? The updated object should still be in the level 2 cache, correct? I dont understand why issuing an UPDATE statement seems to evict the object from the cache. Any ideas appreciated. Thanks

Afaik, changing a property like this updates the session cache correctly, and dirties the query and 2nd level caches. Seeing as you closed a session at the end of step 3, your session cache is gone, so the new session won't find any clean cached records, just dirtied ones, which it ignores. So I think the behaviour is correct.

I suspect that you are right, the behavior is correct, but I'm not sure why the object is not updating the 2nd level cache instead of it just being dirtied. I'm sure there must be a reason but I don't totally understand it and I'm wondering if there is a way to get this behavior.

I believe that the 2nd level cache doesn't store java objects, instead it stores the scalars returned from a result set (meaning that the cache looks like a result set provider, just like a real DB). When you update an object and save it, Hibernate does not automatically select the corresponding row(s) back out of the DB. If it did, the 2nd level cache would be immediately updated, but it would be a huge performance hit. So instead, it just marks that cache entry as invalid, resulting in what you're seeing.

You have to use transactions for the second-level cache to be updated.