Another unnamed CacheManager already exists in the same VM (ehCache 2.5)

Asked 4/4, 2012 at 14:32 Answered 2/3, 2021 at 1:0

This is what happens when I run my junit tests...

Another CacheManager with same name 'cacheManager' already exists in the same VM. Please 
provide unique names for each CacheManager in the config or do one of following:
1. Use one of the CacheManager.create() static factory methods to reuse same
   CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.

The source of the existing CacheManager is: 
 DefaultConfigurationSource [ ehcache.xml or ehcache-failsafe.xml ]

What's the reason behind the exception. Could there be more than 1 cacheManager running simultaneously?

This is how I configured the cachManager using Sping 3.1.1. It sets explicitly the scope of the cacheManager to "singleton"

<ehcache:annotation-driven />

<bean
    id="cacheManager"
    class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
    scope="singleton"
    />

The ehcache.xml looks like

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
     updateCheck="false"
     maxBytesLocalHeap="100M" 
     name="cacheManager"
     >
 ....
 </ehcache>

Finally my class

@Component
public class BookingCache implements CacheWrapper<String, BookingUIBean> {

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

I'm very sure that I'm dealing with only one cacheManager in my code base. Something else is probably running the n-th instance.

Mark answered 4/4, 2012 at 14:32 Comment(5)

I have seen the same issue with ehCache 2.5 or higher. Using 2.4.7 does not cause this problem, but it would be good to know how to make 2.5 friendly with junit. – Mobster 4/4, 2012 at 14:44

Thanks. I switched back to 2.4.7 which is fine for now. There's also a blog entry that discusses possible workarounds (though neither of them seems to be very appealing) norrisshelton.wordpress.com/2012/03/08/… – Mark 5/4, 2012 at 10:57

The Norris Shelton's solution works for me (norrisshelton.wordpress.com/2012/03/08/…) – Peptize 26/4, 2012 at 15:37

This solution doesn't seem to work for me, I'm using testNG though. I still get "Another CacheManager with same name 'myCacheManager' already exists in the same VM" :( – Robot 11/6, 2012 at 11:10

I believe [here][1] solves the problem as well. [1]: #11140153 – Fleer 2/8, 2013 at 12:57

Your EhCacheManagerFactoryBean may be a singleton, but it's building multiple CacheManagers and trying to give them the same name. That violates Ehcache 2.5 semantics.

Versions of Ehcache before version 2.5 allowed any number of CacheManagers with the same name (same configuration resource) to exist in a JVM.

Ehcache 2.5 and higher does not allow multiple CacheManagers with the same name to exist in the same JVM. CacheManager() constructors creating non-Singleton CacheManagers can violate this rule

Tell the factory bean to created a shared instance of the CacheManager in the JVM by setting the shared property to true.

<bean id="cacheManager"
      class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
      p:shared="true"/>

Shipload answered 2/6, 2012 at 17:7 Comment(3)

One thing to note, if Spring is autoproxying the EhCacheManagerFatoryBean you may still get the error even if you set p:shared to true. The way around this is not use the default name for your file, instead of using ehcache.xml rename the file and add p:config-location to your EhCacheManagerFactoryBean declaration with the new file name. – Valence 5/12, 2012 at 20:12

@TechTrip: I've done exactly that: I've got p:config-location="classpath:ehcache-foo.xml" p:shared="true" on my EhCacheManagerFactoryBean, and yet I get a conflict because two WARs on my JVM use this same module. – Irrevocable 10/6, 2013 at 14:23

Correct me if I'm wrong, but doesn't this mean a second test will reuse the cache from the first test with any cached data still in it? This could lead to hard to debug behavior because the second test doesn't start in a well known state. Test result may then depend on test order. (Of course black box tests shouldn't depend on whether or not a cache is used, but it's perfectly valid to have performance tests that depend on cache state or perhaps you are testing your own caching util that uses ehcache under the covers.) – Encephalography 23/3, 2015 at 12:46

I had the same issue with my integration tests using JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). The issue was resolved using following Hibernate configuration:

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

instead of using

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>

Congenital answered 30/1, 2014 at 14:6 Comment(2)

I adapted this solution to fix my Spring Boot testing problems: I used org.hibernate.cache.ehcache.EhCacheRegionFactory instead of net.sf.ehcache.hibernate.EhCacheRegionFactory for Hibernate 4. With Spring Boot you can set this in the application.properties: spring.jpa.properties.hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory or with a @TestPropertySource if you want to limit the configuration to the test. – Horrified 28/6, 2016 at 8:59

Wow , saved my day after upgrading from hibernate 4.3.x to 5.2. – Karenkarena 14/9, 2016 at 8:21

Your problem is the context loading optimization built in the Spring test framework. Spring (per default) does not destroy the context once the test class is done, in hope that another test class might reuse it (instead of creating it from scratch).

You can override this default using @DirtiesContext, or if you use maven you can set surefire forkMode to "always" and create a new VM per test class.

Afoot answered 14/8, 2012 at 15:29 Comment(2)

This solves the issue cleanly for testing environments without changing your actual runtime configuration. Nice! – Calcifuge 14/1, 2013 at 11:1

forkmode=always is a good shout but is deprecated. see: maven.apache.org/surefire/maven-surefire-plugin/examples/… TRY forkCount=1 (default), reuseForks=false – Rote 7/11, 2013 at 11:20

After upgrading to Hibernate 5 I had to use:

<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>

instead of:

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

Please note that the packages differ from each other.

Mosemoseley answered 3/1, 2017 at 21:58 Comment(0)

You may also try to set name"xxx" on your ehcache.xml configuration (on the ehcache element).

That did the trick for me, as I think I had another cache configuration lurking in one of the modules of my app.

The shared solution also works, but I don't know the far-ranging implications of that.

Dorrie answered 24/8, 2012 at 16:35 Comment(7)

Yes! That turned out to be the only solution for me. Adding the name attribute to the top echache element. That doesn't seem to be documented in the example ehcache.xml file.. – Warsle 28/3, 2013 at 15:36

too sad that I read only the first answer here, after that I go back in eclipse reading all the spring & ehcache init source to figure out that the name attribute is needed otherwise the configuration file is ignored... – Twotone 30/12, 2013 at 10:2

good solution, I got the same exception with two unit tests in two different modules that both happened to use ehcache, each with their own file and this solves the issue – Encephalography 7/3, 2014 at 14:38

Excellent. But I still could not understand how it can resolve the issue by putting the name to ehcache.xml? I am using the spring caching + hibernate 2nd level cache. Both are using the the same ehcache.xml. – Gaspard 18/12, 2014 at 8:57

This solution only works with conflicting configurations (several ehcache.xml files), if you use only one then it might be another problem. – Dorrie 13/3, 2015 at 18:19

@MichaelHolst indeed I think there is still another problem because the issue has reappeared for me. I guess I have forgotten an @ DirtiesContext somewhere. – Encephalography 23/3, 2015 at 12:10

In general in a single VM you should only initialize the cache instance once, but for tests it is possible to destroy it and later recreate it. My (second) case of this bug was caused by a second thread in my application initializing the cache before the first thread had destroyed it. – Encephalography 24/3, 2015 at 12:13

For posterity: A better way is to use the "accept-existing" property of the EhCacheManagerFactoryBean.

Umbrageous answered 5/2, 2016 at 5:29 Comment(0)

Setting the EhCacheManagerFactoryBean#shared to true worked for me.

Setting the EhCacheManagerFactoryBean#acceptExisting to true DIDN'T work for me.

import org.springframework.cache.ehcache.EhCacheCacheManager;
import org.springframework.cache.ehcache.EhCacheManagerFactoryBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.ClassPathResource;

@Configuration
public class EhCacheConfiguration {

    @Bean
    public EhCacheCacheManager ehCacheCacheManager() {

        return new EhCacheCacheManager(ehCacheManagerFactoryBean().getObject());
    }


    @Bean
    public EhCacheManagerFactoryBean ehCacheManagerFactoryBean() {

        EhCacheManagerFactoryBean cacheManagerFactoryBean = new EhCacheManagerFactoryBean();

        cacheManagerFactoryBean.setConfigLocation(new ClassPathResource("ehcache.xml"));
        cacheManagerFactoryBean.setShared(true);

        return cacheManagerFactoryBean;
    }
}

As explained in Using EhCache in Spring 4 without XML

Angstrom answered 20/10, 2018 at 10:55 Comment(0)

if you just test your business service,not second level cache,you can remove second level configuration in your spring config file,your test will be run successfully. there is my second level configuration :

 <bean id="entityManagerFactory"
        class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="persistenceUnitName" value="defaultPU" />
        <property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
        <property name="jpaProperties">
            <props>
                <prop key="hibernate.dialect">${hibernate.dialect}</prop>
                <prop key="hibernate.show_sql">false</prop>
                <!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
                <prop key="hibernate.cache.use_second_level_cache">false</prop>
                <prop key="hibernate.cache.use_query_cache">false</prop>
            </props>
        </property>
    </bean>

if i change to full configuration of second level cache config ,the real webapp use in running time,like this:

    <bean id="entityManagerFactory"
            class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
            <property name="dataSource" ref="dataSource" />
            <property name="persistenceUnitName" value="defaultPU" />
            <property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
            <property name="jpaProperties">
                <props>
                    <prop key="hibernate.dialect">${hibernate.dialect}</prop>
                    <prop key="hibernate.show_sql">false</prop>
                    <!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
                    <prop key="hibernate.cache.use_second_level_cache">true</prop>
                    <prop key="hibernate.cache.use_query_cache">true</prop>
                    <prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</prop>               
                    <prop key="net.sf.ehcache.configurationResourceName">ehcache/ehcache-hibernate-local.xml</prop>
                </props>
            </property>
        </bean>

then i get the same Exception "Another unnamed CacheManager already exists in the same VM"

Perspective answered 30/9, 2013 at 6:48 Comment(0)

In my case, we have a custom cache manager defined as bean. Also a custom application context so we don't use the spring junit runner... hence the @DirtiesContext doesn't work.

The trick is to retrieve the cache instance from the bean, on that cache get the cacheManager (the instance from EHCache). and on that cachemanager call the removeCache method.

Put this in a method annotated with @After and your cache is removed from the VM after each test. Like this:

@After
public void destroy() {
    MyCustomCacheManager customCacheManager = (MyCustomCacheManager) context.getBean("yourCustomCacheManagerBean");

    try {
        net.sf.ehcache.Cache cache = customCacheManager.getCache();
        net.sf.ehcache.CacheManager cacheManager = cache.getCacheManager();
        cacheManager.removeCache("nameOfYourCache");
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }

    context.destroy();
    context = null;
}

Pamilapammi answered 31/10, 2014 at 7:39 Comment(0)

I solved it by adding following to resources.groovy :

beans = { ... aclCacheManager(EhCacheManagerFactoryBean) { shared = true } ... }

Interminable answered 3/10, 2015 at 11:24 Comment(0)

It happened to me when switching to Spring Boot 2.0.2. Resolved it by doing the following:

REMOVE in application.yml

spring.jpa.properties.hibernate.cache.region.factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory

REMOVE in pom.xml

<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
</dependency>

KEEP in pom.xml only

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-ehcache</artifactId>
</dependency>

Omnipotence answered 14/5, 2018 at 8:16 Comment(0)

For future readers, the cause of this problem in my case was that in my pom.xml file I had imported the hibernate-ehcache library, which unknown to me also already contained the ehcache library, and then explicitly imported the net.sf.ehache libray.

This seemed to work fine when I was running as a standalone app (a command line utility for example) but it caused the error in the original post when running on a tomcat server.

Changing my pom file from:

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-ehcache</artifactId>
            <version>5.0.2.Final</version>
        </dependency>
        <dependency>
            <groupId>net.sf.ehcache</groupId>
            <artifactId>ehcache</artifactId>
            <version>2.7.4</version>
        </dependency>

To:

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-ehcache</artifactId>
            <version>5.0.2.Final</version>
        </dependency>
        <!-- ehcache dependency removed -->

Fixed the problem. If anyone has any idea why the problem only appeared when running in a tomcat container I'd be interested to know..

Delanadelancey answered 11/2, 2016 at 13:37 Comment(0)

In glassfish 3.0.1, I traced the issue to IniShiroFilter getting initialize twice, which happens when concurrent requests are fired just after the server start. Following is a stack trace from two different threads corresponding to two HTTP requets:

[#|2012-11-28T08:25:10.630-0800|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=28;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1249)
        at org.apache.shiro.web.servlet.IniShiroFilter.<init>(IniShiroFilter.java:124)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:303)
        at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:725)
        at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1948)
        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:248)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
        at com.sentilla.filter.DumpFilter.doFilter(DumpFilter.java:152)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
        at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
        at java.lang.Thread.run(Thread.java:662)

Another thread

[#|2012-11-28T08:25:15.299-0800|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1249)
        at org.apache.shiro.web.servlet.IniShiroFilter.<init>(IniShiroFilter.java:124)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:303)
        at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:725)
        at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1948)
        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:248)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
        at com.sentilla.filter.DumpFilter.doFilter(DumpFilter.java:152)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
        at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
        at java.lang.Thread.run(Thread.java:662)

Looking at the stack trace ApplicationFilterConfig.java:248 could be the culprit. Or, glassfish is initializing filters in the wrong context, for comparison, Tomcat initializes filters during BootStrap.

Midgett answered 20/11, 2012 at 0:42 Comment(0)

In my case Problem is component-scan and java config.

root-context.xml
<context:component-scan base-package="org.beansugar">

servlet-context.xml
<context:component-scan base-package="org.beansugar">

spring component-scan work two times on xml files. it generate beans inside SpringConfig.java each run time. then duplicate cache manager was created.

so, I changed that like below.

root-context.xml
<context:component-scan base-package="org.beansugar">
        <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

servlet-context.xml
<context:component-scan base-package="org.beansugar" use-default-filters="false">
        <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

Cholesterol answered 27/8, 2014 at 5:11 Comment(0)

This error also happens with wrong mapping files. The message is horrible, doesn't say the cause.

Whitethroat answered 16/2, 2016 at 12:26 Comment(0)

In my case configuration was as follows:

<spring.boot.version>1.5.8.RELEASE</spring.boot.version>
<spring.boot.yarn.version>2.4.0.RELEASE</spring.boot.yarn.version>
<spring.version>4.3.7.RELEASE</spring.version>

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-core</artifactId>
  <version>3.5.1-Final</version>
</dependency>
<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-ehcache</artifactId>
  <version>3.5.1-Final</version>
</dependency>

Changing the EHCache provider class did the job for me. I was using cache provider class as org.hibernate.cache.EhCacheProvider instead i changed this to: net.sf.ehcache.hibernate.SingletonEhCacheProvider

Loggins answered 13/11, 2018 at 8:55 Comment(0)

As of Spring Boot 2.1.2 the following configuration worked to resolve the issue. (Note, these are snippets of the overall config.)

Dependencies:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-core</artifactId>
  <version>5.2.8.Final</version>
</dependency>
<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-ehcache</artifactId>
  <version>5.2.8.Final</version>
</dependency>

application.yml config:

spring:
  jpa:
    open-in-view: false
    hibernate:
      ddl-auto: none
    show-sql: true
    properties:
      dialect: org.hibernate.dialect.MySQLDialect
      net:
        sf:
          ehcache:
            configurationResourceName: ehcache.xml
      hibernate:
        cache:
          use_second_level_cache: true
          region:
            factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory

ehcache.xml configuration:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
  <!-- Required elements -->
  <diskStore path="java.io.tmpdir"/>
  <defaultCache
    maxElementsInMemory="10000"
    eternal="false"
    timeToIdleSeconds="120"
    timeToLiveSeconds="120"
    overflowToDisk="true"/>

  <!-- Cache settings per class -->
  <cache name="com.mystuff.component.services.example.Book"
    maxElementsInMemory="1000"
    eternal="false"
    timeToIdleSeconds="300"
    timeToLiveSeconds="600"
    overflowToDisk="true"/>
</ehcache>

The application I am working on slows down drastically without a working cache. So, to validate I simply ran the application and hit one of the read intense endpoints.

Calabro answered 9/2, 2019 at 14:51 Comment(0)

In my case the Manager was created by this bean (ehCache 2.10):

  <bean id="ehcache"
        class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
    <property name="shared" value="false"/>
  </bean>

the only solution that worked for me is to destroy it manually in that way :

@Inject
private EhCacheManagerFactoryBean ehCacheManagerFactoryBean;

And then

ehCacheManagerFactoryBean.destroy();

Brotherton answered 2/3, 2021 at 1:0 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags