Cache.getManager() not available if CacheLoader is configured decalratively

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: 2 Major 2 Major
  • Resolution: Unresolved
  • Affects Version/s: 2.5.1
  • Fix Version/s: None
  • Component/s: ehcache-core
  • Labels:
    None
  • Terracotta Target:
    Pending

Description

I have a cache loader that needs to access another (local-)transactional cache, before doing the actual loading.

When I try to get the CacheManager from Cache object it is not available. This is because both CacheLoaderFactory.createCacheLoader() nor in CacheLoader.init() are called inside the CacheManager constructor.

This can be solved by configuring the loader programmatically, so I think the same should be available for declarative configuration.

Another thing I found while doing this is that the porgrammatic registeration of CacheLoader doesn't invoke the init() method.
Does it mean the dispose() method will not be called also?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Alex Snaps added a comment -

When you setup your CacheManager, whether through a XML config or programmatically, they CacheLoaderFactory will always get a non-initialized cache passed in.
That's why you can't get to the Manager (yet). If you register the CacheLoader after the cache is initialized. That's a different story.
init() (or dispose()) will only be called when the Cache (through the CacheManager) manages the lifecycle of that Loader.
That means that if the cache gets initialized, having a registered loader, it will get init called on it. If it is disposed, with a registered loader, that also will call dispose on it.
As you do register your loader manually after the cache is started, it is your duty to pass an initialized instance in. If the loader needs disposal, and you unregister it before disposing the cache, it is also your duty to dispose the loader manually.
On the other hand, if the loader is still registered a cache disposal time, then the cache will dispose it.
Does that make sense ?

Show
Alex Snaps added a comment - When you setup your CacheManager, whether through a XML config or programmatically, they CacheLoaderFactory will always get a non-initialized cache passed in. That's why you can't get to the Manager (yet). If you register the CacheLoader after the cache is initialized. That's a different story. init() (or dispose()) will only be called when the Cache (through the CacheManager) manages the lifecycle of that Loader. That means that if the cache gets initialized, having a registered loader, it will get init called on it. If it is disposed, with a registered loader, that also will call dispose on it. As you do register your loader manually after the cache is started, it is your duty to pass an initialized instance in. If the loader needs disposal, and you unregister it before disposing the cache, it is also your duty to dispose the loader manually. On the other hand, if the loader is still registered a cache disposal time, then the cache will dispose it. Does that make sense ?
Hide
Permalink
Jakub Bochenski added a comment -

Thank you for the clarification.

I think that the javadoc could benefit from including this information there - both about passing uninitialized instances and the init/dispose behaviour.

I understand I can configure a cache listener that will setup the desired loader.
What I'm suggesting is that, because it's already supported, it should be easier to configure this declaratively. E.g. now I have all the configuration in the .xml file and only this single loader is configured programmatically - not good for maintenance.

While anybody can implement a custom cache loader as you suggested, I think that EHCache could benefit from providing a standard configuration option for that. Weather it would be an additional attribute on the cacheLoaderFactory or just a custom CacheListener it's up to you.

Show
Jakub Bochenski added a comment - Thank you for the clarification. I think that the javadoc could benefit from including this information there - both about passing uninitialized instances and the init/dispose behaviour. I understand I can configure a cache listener that will setup the desired loader. What I'm suggesting is that, because it's already supported, it should be easier to configure this declaratively. E.g. now I have all the configuration in the .xml file and only this single loader is configured programmatically - not good for maintenance. While anybody can implement a custom cache loader as you suggested, I think that EHCache could benefit from providing a standard configuration option for that. Weather it would be an additional attribute on the cacheLoaderFactory or just a custom CacheListener it's up to you.

People

  • Assignee:
    Chris Dennis
    Reporter:
    Jakub Bochenski
Vote (0)
Watch (5)

Dates

  • Created:
    Updated: