when I call the following query similar to the below:

'select u from User as a
join fetch groups '

On the first call of the query : I receive the auction entity with an eagerly fetched 1:m or m:m association groups.

on the second call of the query , the query is cached and the auction is returned with a null set for the association UNLESS within a transaction in which case the proxy is invoked .

this ultimately causes a lazy initializationException since the code is passing around a detatched entity

the only way around this is to set all associations as eager which is not a good idea.

I have tried @Cache(usage = CacheConcurrencyStrategy.READ_WRITE,include="all") to include lazy and non lazy, however this doesnt fix the issue:

below are the jars and 2nd level cache provider Im using.

<property name="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</property>

Hibernate3.jar : 3.2.4 sp1
Hibernate-entitymanager.jar : 4.2.3.GA

terracotta-toolkit-1.1-runtime-2.1.0.jar
ehcache-core-2.3.2.jar
ehcache-terracotta-2.3.2.jar

ps: I started on the ehcache forums but they suggested this forum first.

Hi, welcome.

Of course, you should always work in the scope of a transaction, especially when loading data. The fact that you enable caching or not is meant as a transparent optimization, but it should never affect the semantics, so you should not rely on having a cache to "fix behaviour".


I don't consider this as an issue: sorry but your usage of caches is broken to say the least. You should never access entities out of the scope of a session or entitymanager unless you're doing something very specific and don't expect more data to be loaded - loading from a cache as well.


that's very old, many things changed around caching. I 'm not sure that such a new version of ehcache-core works with it: wasn't tested.


they are not needed if you're using the HashtableCacheProvider

This is the way the hibernate caching works: it's meant to be transparent to the applications. If you want a different behaviour I'd recommend to instantiate a cache directly and control it: that's an application cache, not a session cache. (A session cache needs an open session ;).

thanks for the detailed reply,

each call of the query occurs within the context of an ejb method and so is within the scope of a transaction.
the query specifies an explicit fetch which I thought would include the collection and not a proxy.

the data from the entity is then copied into a data transfer object and so I dont expect any more data to be loaded.

yes , the new version of ehcache-core works with pre 3.3 and post 3.3 Hibernate , there is a minimal change configuration of echache.

I was asked to try using HashtableCacheProvider ratther than the ehcache provider just to check whether ehcache is mirroring the behaviour of Hibernate. ( the actual implementation is using ehcache) to find out whether the potential issue lies with hibernate or ehcache implementation.

many thanks. :)

ok, so you have a transaction. why don't you open a session as well? A session is extremely cheap, it's only the context in which hibernate works. (no session -> don't rely on Hibernate).

Hibernate will not open a database connection unless it's needed, so if all you do is load data from the cache you could even power off the database and still load stuff, but the Session is still needed.

Remember that data stored in the caches is made up of single attributes, it's not going to store entity instances as that would make it impossible to isolate state from different threads: so it's not storing your entity with it's relations, but it needs to re-hidratate your entities and all relations from the values in the cache: it needs a Session as a conversion context.

Thankyou .

I made an implicit assumption that the injected entitymanager was a new instance for each jpa query, thus a new session was being used. . Apparently not.

now the explicit fetch within the query works and I can now breath a sigh of relief !

you're welcome