FYI: Cause of multiple front caches in server environment

Question

Hi All.
Long time lurker, first time poster here. With this post I would just like to contribute with some information about a problem we recently solved at my work place.
We have Coherence deployed in an app server environment. We discovered that our distributed schemes ended up having two front-caches by looking in the JMX. We got several instances of the same
type of CacheMBean with different 'loader' arguments, like this:
Coherence:type=Cache,service=DistributedCache,name=SomeCache,nodeId=3,tier=front,loader=x
Coherence:type=Cache,service=DistributedCache,name=SomeCache,nodeId=3,tier=front,loader=y
By trial and error we finally concluded that the cause of this was that, unless told otherwise, Coherence utilizes the context class loader (Thread#getContextClassLoader()) to fetch the front cache. In our case the context class loader
differed depending on the entry point of our application. Web calls had one context class loader, and EJB calls another. The undesired side effect was that we ended up with separate front caches for web and EJB calls. This is of course not ideal.
In order to fix this, one can specify which class loader to use when fetching the cache from CacheFactory: http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/CacheFactory.html#getCache(java.lang.String, java.lang.ClassLoader)
The documentation already makes clear that the class loader is used for serializing. It is apparently also used for more.
For us the fix was to specify getClass().getClassLoader(), which will vary only depending on the type of the calling instance, not vary depending on entry point. As a side note, this also worked well for us when mixing transactional and non-transactional interactions with the caches.
Best regards,
Alexander

Answer 1

933421 wrote:
Hi All.
Long time lurker, first time poster here. With this post I would just like to contribute with some information about a problem we recently solved at my work place.
We have Coherence deployed in an app server environment. We discovered that our distributed schemes ended up having two front-caches by looking in the JMX. We got several instances of the same
type of CacheMBean with different 'loader' arguments, like this:
Coherence:type=Cache,service=DistributedCache,name=SomeCache,nodeId=3,tier=front,loader=x
Coherence:type=Cache,service=DistributedCache,name=SomeCache,nodeId=3,tier=front,loader=y
By trial and error we finally concluded that the cause of this was that, unless told otherwise, Coherence utilizes the context class loader (Thread#getContextClassLoader()) to fetch the front cache. In our case the context class loader
differed depending on the entry point of our application. Web calls had one context class loader, and EJB calls another. The undesired side effect was that we ended up with separate front caches for web and EJB calls. This is of course not ideal.
In order to fix this, one can specify which class loader to use when fetching the cache from CacheFactory: http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/CacheFactory.html#getCache(java.lang.String, java.lang.ClassLoader)
The documentation already makes clear that the class loader is used for serializing. It is apparently also used for more.
For us the fix was to specify getClass().getClassLoader(), which will vary only depending on the type of the calling instance, not vary depending on entry point. As a side note, this also worked well for us when mixing transactional and non-transactional interactions with the caches.
Best regards,
AlexanderHi Alexander,
depending on which appserver you use, you would probably want to go with a classloader which is a common root of the EJBs and web-apps. Depending on where your data classes reside, and what appserver you use, this may be an ejb-tier-wide classloader, or the ear classloader.
Best regards,
Robert