Description of what I'm doing:
First of all, I'm using hibernate 3.3.1
I'm trying to performance tune some code which (amongst other things) reads back an entity which has references to numerous transitively persisted objects. The entity being read back is read/write and is therefore not that useful to cache, but its transitively persisted objects are all read-mostly and therefore I'd hope that caching them would give some performance benefits.
Unfortunately, these related objects are all related to the base entity in the schema by foreign keys which points to a unique id in the other table (i.e. using a property-ref attribute in the "many-to-one" mapping. e.g (package names removed to protect the innocent):
Code:
<!-- snippet -->
<many-to-one
name="relatedObject"
column="ro_tid"
property-ref="relatedObjectTid"
class="com.wesuck.RelatedObject"
not-null="false"
lazy="false"
/>
<!-- snippet -->
I noticed that despite the fact that com.wesuck.RelatedObject had been blithely included in the second level cache configuration, every time it gets read back via this assocation, the application hits the database, whereas under ordinary circumstances it hits the cache.
I made a vain attempt to follow what was actually happening under the covers and it seemed that the code eventually ended up in the EntityType.loadByUniqueKey method, which (interestingly) contains a comment at the top reading:
Code:
//TODO: implement caching?! proxies?!"
(Have I answered my own question?).
It seems like from there, the code goes into the EntityPersister to read the object back from the database, whereas if the relationship was a normal PK one, the EntityType obtains the object via a Session.load, which checks the second level as well as lots of other good stuff (probably).
What I want to know
Is my understanding of what's going on here correct? Is this expected behaviour? How can I get entities associated via a property-ref to get read via the second level cache?