35

This link (from the creator of Ehcache) says you should use SingletonEhCacheRegionFactory when you only have one Hibernate SessionFactory, and EhCacheRegionFactory when you have multiple.

But wouldn't EhCacheRegionFactory be a single instance anyway when you only have one SessionFactory?

So, what's better about SingletonEhCacheRegionFactory? Why not use EhCacheRegionFactory all the time since it can be used for one SessionFactory or multiple?

FYI: I'm using Ehcache 2.4.2 and Hibernate 3.6.5

Brad Cupit
  • 6,530
  • 8
  • 55
  • 60
  • 1
    The phrase "de facto singleton" is a bit strange, if not meaningless. If your class is guaranteed to have at most one instance then it's a singleton, if not then it's not. If in practice you have at most one instance, but you could still create extra instances, no matter how useless they are, then it's not a singleton. As far as I understand you can make as many instances of EhCachRegionFactory as you want (using the public constructor), regardless of how many session factories you have. Maybe I'm missing the point of your question. If so, please point out what I missed. – Rinke Oct 04 '11 at 07:31
  • 2
    Maybe using a AbstractSingletonEhCacheRegionProxyBeanFactory will solve the problem? – GreenieMeanie Oct 18 '11 at 18:35
  • @GreenieMeanie it's not so much a _problem_ as it is question. Which is best? – Brad Cupit Oct 18 '11 at 23:42
  • 1
    @Rinke I'm basically questioning why SingletonEhCacheRegionFactory exists. It seems EhCacheRegionFactory would serve the same purpose, so long as you only configure/instantiate one instance. Maybe SingleonEhCacheRegionFactory is faster, or uses less memory, etc.? – Brad Cupit Oct 18 '11 at 23:46

2 Answers2

10

The non-singleton EhCacheRegionFactory allows you to configure EHCache separately for each Hibernate instance using net.sf.ehcache.configurationResourceName property. The SingletonEhCacheRegionFactory shares the same EHCache configuration among all Hibernate session factories.

EHCache documentation recommends to use the non-singleton version.

Edit: This information applies to EHCache 2.8. Not sure how many things have changed in the latest version.

Matej
  • 6,004
  • 2
  • 28
  • 27
  • 2
    Thanks for the link. The link mentions using the non-singleton version when you have multiple caches, but the original question links to a bug that says "It is preferable to use the SingletonEhCacheProvider". I just don't understand why. – Brad Cupit Oct 18 '11 at 23:51
  • 1
    @BradCupit I've finally noted your link to Hibernate JIRA. You should probably drop an email directly to the reporter why it is preferred. I've quickly reviewed the comments as well as the attached source but I haven't been able to reach some conclusion within the time that I can give to this. – Matej Oct 19 '11 at 17:08
  • @BradCupit did you have a chance to ask on the mailing list why singleton is not preferred? – Bence Olah Feb 20 '15 at 15:27
  • @BenceOlah I have not asked. If you're thinking about doing it please let me know what they say! – Brad Cupit Feb 20 '15 at 16:51
  • 1
    @palacsint See http://www.ehcache.org/documentation/2.8/integrations/hibernate#optional It is related to v2.8. Things seems to be changed a bit in v2.10. I haven't used EHCache for a while and you might need to revisit the current documentation to find the appropriate approach for you. – Matej Apr 27 '15 at 09:22
  • 1
    @palacsint fixed the link – Brad Cupit Jan 31 '19 at 21:46
0

I guess by using SingletonEhCacheRegionFactory you don't need to maintain (or make sure) that EhCacheRegionFactory is a singleton. You can create new SingletonEhCacheRegionFactory() anywhere, and it will still be a singleton within the entire application.

While with EhCacheRegionFactory, you need to explicitly configure the object's scope accordingly to make sure that it's singleton.

  • with hibernate the class name is listed in an XML file, so you don't control whether it's a singleton or not – Brad Cupit Aug 04 '11 at 13:32