When would the below mapping result in an outer-join fetch for the two many-to-one Cats?

I am properly getting the expected 1 outer-join for the Dog. Surprisingly, however, I am getting the Cats outer-joined as well.

I am using a standard session.get(OwningEntity.class, entityID) to retrieve the owning entity.

Since the Cats are not marked at all, I would expect them to load via proxy (e.g. lazily) and not be loaded at all. The Cat mapping files do not have a lazy="false" annotation on their class.

What's causing the Cats to be eagerly outer-join fetched?

This is not the actual code example that I am using, but rather a dummied (and hopefully congruent) version. What else should I be looking for?

Hibernate version: 3.1.2

Mapping documents:


Configuration:
hibernate.max_fetch_depth = default out-of-the-box setting

Tracing through the code I find that the EntityPersister (a SingleTableEntityPersister) for the owning entity creates several loaders for each lock type (e.g. READ, NONE, UPGRADE-NOWAIT, refresh, etc.) It uses a TreeWalker to generate the SQL, and deep down in there, there is a call to JoinWalker.isJoinedFetchEnabledInMapping().

This method is returning an OUTER JOIN for the two cats, not because of FetchMode = JOIN or SELECT but because of "Hibernate default semantics" that will automatically try an outer join if the associated class does not have a proxy.

So this question reduces to, why would the above Cats not have proxies?

I thought all classes by default are lazily loaded in Hibernate 3.1.2.

Will continue digging deeper.

Figured it out.

My "Cat" class was marked "final".

Final classes can not be enhanced by CGLIB and hence do not get a proxy.
That is why I was getting the cats eagerly fetched.

Also make sure you provide a public no-arg constructor.