Can NHibernate load data from 2nd level cache after session is closed? - caching

Question

I am trying stuff I can make with NHibernate for my app. I am using quite a lot of "dictionaries" to store all possible values for certain object properties. I've tried playing with 2nd level cache to store those dictionaries data in there. Now I wonder if there is a way to load needed data from cache after the session is closed. Let's say that is my code:
public class Class1 {
public virtual int Id { get; set; }
public virtual Dic1 Dic { get; set; }
}
public class Dic1 {
public virtual int Id { get; set; }
public virtual string Name { get; set; }
}
and here are the mappings:
<class name="Class1" table="class1">
<id name="Id" column="id">
<generator class="native" />
</id>
<!-- I want to try not to use fetch="join" here -->
<many-to-one
name="Dic"
class="Dic1"
column="dic1_id"
/>
</class>
<class name="Dic1" table="dic1">
<cache usage="read-write"/>
<id name="Id" column="id">
<generator class="native" />
</id>
<property name="Name" column="name" />
</class>
If I get value of Class1.Dic object before I close the session, NHibernate does not send query to the database, because value was cached by some earlier query.
But let's say, I've closed the session. In debug session, Class1.Dic is an object of Dic1Proxy type and I get an exception when I try to access it/it's properties. Is there a way to load that data after session is closed? 2nd level cache is connected to session factory, so maybe there is a way to actually turn that Proxy into the right object? Or actually force to always load those values without changing fetch method to join.

Answer 1

You can use NHibernateUtil.Initialize(class1.Dic); before closing the session. It will do nothing if the object is not actually a proxy or if it is already loaded, otherwise it will load it (from the second level cache if cached).
You can also force eager fetching while keeping the default select fetch mode: set lazy as false on the many-to-one mapping of the Dic property. Loading a Class1 will then trigger immediately a load of the Dic property. It should fetch it from second level cache if it is in it. Beware that this will cause n+1 loads issues if you query a list of Class1 and if their Dic property is not cached, even if you have enabled batching of lazy loads.
Otherwise if you do not want to do any kind of manipulation on your Dic property before closing the session, you need to change the proxy implementation for it to first check the second level cache before failing if the session is already closed. But this will require too much work to be worth it, in my opinion. (Moreover, what if the entity is missing in the cache anyway? Is it acceptable for your application to fail in such case?)
NHibernate allows you to supply your own factory of proxy factory (IProxyFactoryFactory), by using the proxyfactory.factory_class optional setting, provided you use the default bytecode provider.
Then you would need to implement your own IProxyFactoryFactory, which would likely mostly be a copy of StaticProxyFactoryFactory with BuildProxyFactory yielding a custom proxy factory.
The custom proxy factory would itself likely be mostly a copy of StaticProxyFactory, with GetProxy using a custom ILazyInitializer at this line.
The custom lazy initializer would in turn be likely a copy of LiteLazyInitializer, but with an override of Initialize. Its implementation is here.
That is for the easy part, and till there, that is not as bad as it sounds, that does not involve copying so many lines of code.
Now for the override of Initialize, it would need to check the Session property and acts accordingly, calling its base implementation if the session is usable, or trying to directly load from the second level cache otherwise.
Here you would have more code to duplicate, mainly LoadFromSecondLevelCache and AssembleCacheEntry.
You will also need the persister, which is easy to get if you have the session factory: sessionFactory.GetEntityPersister(EntityName). (ILazyInitializer has an EntityName property.)
As you can see by checking their code, these functions use at many points the session:
CacheMode: checked for ensuring the cache is enabled for the session, you surely should skip that check for your use case.
GenerateCacheKey: easy to inline out of the session, see its code.
Timestamp: using sessionFactory.Settings.CacheProvider.NextTimestamp() instead should do it.
Instantiate: use subclassPersister.Instantiate(id) instead. (Unless you have an interceptor to which it should be delegated.)
The other calls are more troublesome.
You will have to give-up on safe-keeping from circular references as this uses the session persistence context.
Then there is the Assemble and DeepCopy logic which use the session. Many cases just call its Factory property, so depending on the property types of your entities, a dummy session just actually supplying the factory may do.
Skip the readonly stuff if possible, otherwise you will have still more work to do.
Skip most of the persistenceContext stuff: that is the session first level cache. Still there is the InitializeNonLazyCollections call which will be lacking if your entities have some.
About AfterInitialize, this call is currently needed for handling entities having lazy properties (not being an entity or a collection). So you may be able to skip it.
And finally, the PostLoadEvent is there for entities implementing ILifecycle: again, you may be able to skip it, provided you do not use ILifecycle.
If you have also some cached collections to retrieve from the second level cache without a session, you would need to do a similar work with the collection type factory, configurable with the collectiontype.factory_class, providing your own ICollectionTypeFactory yielding collection types overriding Initialize, likewise duplicating the loading from second level cache.
Good luck if you try this.