Can anyone provide any assistance with the second level cache in hibernate. I am relatively new to this area and I am experiencing some unexpected behaviour.
I am using JBoss AS 5.01 with JBoss cache as follows:




Before I go any further I know the second level cache and query cache is working as I have viewed the cache contents and regions via the JMX console and also monitor the SQL output from hibernate by configuring log4j as follows:

I can see hibernate starting regions and returning results from cache and not executing the SQL.


I have a scenario involving three entities and a query which does not behave the way I thought it would.
Here is a simplified representation of the problem I am having:





As you can see I have three entities (all of which are cachable), a named query (which is cached) and an association from EntityA which is a Map of EntityC's to EntityB's (one to many lazy association which is also marked for caching).

The first time I execute the query everything works as expected.
Here is a log extract:




If I now open the JMX console and look at the query cache and entity cache the query results are indeed cached ( i can see the correct id's) and the entity cache has regions for each entity and I can see the state in dehydrated form including the association value mapping.

Now if I re-execute the same query I get this in the logs:



No SQL executes
So far so good. Then...
LazyInitializationException occurs attempting to access entityA.association.

This is where I am confused. The entities are all cached, the query is cached and the association is also cached. I can see all the relevant data in the query cache and entity cache and no SQL is executing (as expected). Why does hibernate not populate the association in entityA when it re hydrates it?

Perhaps rather interestingly if i mark the association as EAGER fetch OR if I navigate the association in my EJB directly after running the named query the LazyInitializationException no longer occurs AND NO SQL is run. It appears when we tell it to eager fetch or navigate it realises it is in the cache but when we don't it does not bother to look?
Is this expected behaviour or have I missed something?

Looking at the Java-Doc of LazyInitializationException


I guess that Hiberante does always check the session state before populating the association,
regardless if the then association can be fetched from 2L-cache or not.

Thank you for your reply.

I appreciate what you are saying, I just find it slightly odd considering the following points;
1) The query which originally put the entity in the cache was fetching the association.
2) The collection and associated entities are visible in the entity cache.
3) The second time we run the cached query if we navigate the collection or apply an eager fetch strategy it starts to work without hitting the database whatsoever.

It just seems a little odd/unexpected that everything it needs is there and if we give it a nudge it does pick up the required data without a DB access.
Perhaps this is more of a misunderstanding on my part about how this is meant to work rather than a "problem" with the 2L-cache.

Perhaps someone with a deeper knowledge of the caching than me can provide some incite into this behavior?

Hi David,

I just take a look at the code of Hibernate and in fact it is like I guessed:
see lines 368 and 369 below:
-first hibernate checks the state of the session
-if the check goes well, hibernate begins to initialize the collection

According the documentation this is expected behavior.

And my question to you:
Why for gods sake do you close the session before accessing entityA.association. ?


class AbstractPersistentCollection:

Hi,
Thanks once again for replying so quickly. OK, what you are saying makes more sense to me now.



I see what you are saying here. I guess I was perhaps hopeful in this case that somewhere within this method call (or else where for that matter) hibernate might realise that even though we are not attached to an active session we don't actually need to be in order to fetch the required data as it is all readily available in the 2L cache. As I said I am not knowledgeable in this area and it is most likely that I have overlooked the way in which it is supposed to work. It just came as a surprise to me, that is all.

The reason the session is closed is because my EJB method which runs the named query and returns the list of entities is being called from the web tier of my application (a Struts 2 Action). My Stateless Session Bean is completely container managed in regards to transactions and so forth so the session is closed once the method call finishes. It is my Struts 2 action which is attempting to access the key set of the map association in order to display some information on a JSP.

Am I using this in a way that it was not designed to be used?