Hibernate version:3.2.1

Ehcache version:1.2.3

Postgres 8.0.12

I have modified a set of persistent objects in my Hibernate-enabled application to use the READ_WRITE CacheConcurrencyStrategy.
My objects consist of:
User
User.Container
User.Container.Collection of XXX objects
an XXX object is a graph of 8-10 other objects - all of which use
the READ_WRITE annotation

I'm seeing the following behavior:
- On a create of XXX, all of the objects are loaded into the 2nd level cache
(ehcache). (this is what I expect) I've verified this by looking up cache
statistics for the individual caches - I'm seeing this in a controlled
environment where my tests are creating and reading the objects
one at a time.

- When I first read the XXX collection after it's been created, Hibernate
performs a read from the database. This is unexpected behavior
From the Hibernate logging I see (in ReadWriteCache.java):
- Cache lookup User
- Cache hit
- Cache lookup User.Container
- Cache hit
- Cache lookup User.Container.Collection
- Cached item was locked

I assume that it is this last condition that causes the database read.

After a slight pause in the logging I see a series of:
- Caching XXX
- Item was already cached
for each object in the XXX graph.

Subsequent reads after the inital read come directly from the cache and bypass the database lookup.

The logging during the subsequent reads indicate a cache hit for the
User.Container.Collection collection and there is no pause in the
log following that cache hit.

Looking at the code in ReadWriteCache, it appears to me that the call to
lockable.isGettable(txTimestamp) is failing - which indicates the passed in timestamp is >= the timestamp on the cached item.
But I am pausing several seconds between the create and the read, so that doesn't seem to make sense - the timestamp is set when the cached object is created and never modified.

Can anyone explain why this could be happenning?
I'm trying to insure that I always get the cached objects, when available,
for performance purposes.

Thanks

I changed the annotation on the collection that was causing the
database lookup from FetchType.LAZY to FetchType.EAGER and
it looks like this solved my problem. Initial and subsequent reads
all bypass the database and come from the cache, as I expected.