У тій самій віртуальній машині вже існує інший неназваний CacheManager (ehCache 2.5)


76

Це те, що відбувається, коли я запускаю свої тести на джуніт ...

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 ]

У чому причина винятку. Чи може одночасно працювати більше 1 cacheManager?

Ось як я налаштував cachManager за допомогою Sping 3.1.1. Він явно встановлює область дії cacheManager на "singleton"

<ehcache:annotation-driven />

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

Виглядає файл ehcache.xml

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

Нарешті мій клас

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

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

Я дуже впевнений, що маю справу лише з одним cacheManager у своїй базі коду. Щось інше, ймовірно, працює на n-му екземплярі.


4
Я бачив ту ж проблему з ehCache 2.5 або вище. Використання 2.4.7 не викликає цієї проблеми, але було б непогано знати, як зробити 2,5 дружнім з junit.
aweigold,

1
Дякую. Я повернувся до 2.4.7, що наразі добре. Також є запис у блозі, де обговорюються можливі обхідні шляхи (хоча жоден з них, здається, не дуже привабливий) norrisshelton.wordpress.com/2012/03/08/…
simou,

Рішення Норріса Шелтона працює для мене ( norrisshelton.wordpress.com/2012/03/08/… )
jbbarquero

Здається, це рішення не працює для мене, однак я використовую testNG. Я все ще отримую "Інший CacheManager з тим самим іменем 'myCacheManager' уже існує в тій самій ВМ" :(
nodje

Я вважаю, [тут] [1] також вирішує проблему. [1]: stackoverflow.com/questions/11139653 / ...
Lekkie

Відповіді:


46

Ваш EhCacheManagerFactoryBean може бути єдиним, але він створює кілька CacheManagers і намагається дати їм одне і те ж ім’я. Це порушує семантику Ehcache 2.5 .

Версії Ehcache до версії 2.5 дозволяли будь-якій кількості CacheManagers з однаковим іменем (однаковим конфігураційним ресурсом) існувати в JVM.

Ehcache 2.5 та новіші версії не дозволяють декільком CacheManagers з однаковим іменем існувати в одній JVM. Конструктори CacheManager (), що створюють не-Singleton CacheManagers, можуть порушити це правило

Попросіть фабричний компонент створити спільний екземпляр CacheManager в JVM, встановивши для спільного властивості значення true.

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

5
Зауважимо одне, якщо Spring автоматично проксірує EhCacheManagerFatoryBean, ви все одно можете отримати помилку, навіть якщо для p: shared встановлено значення true. Навколо цього не використовується ім’я за промовчанням для вашого файлу, замість того, щоб використовувати ehcache.xml, перейменуйте файл і додайте p: config-location до своєї декларації EhCacheManagerFactoryBean з новою назвою файлу.
TechTrip

1
@TechTrip: Я зробив саме це: я потрапив p:config-location="classpath:ehcache-foo.xml" p:shared="true"на свій EhCacheManagerFactoryBean, і все ж я отримую конфлікт, оскільки дві ВІЙНИ на моїй JVM використовують цей самий модуль.
mcv

3
Виправте мене, якщо я помиляюся, але чи не означає це, що другий тест повторно використовуватиме кеш із першого тесту з будь-якими кешованими даними, які все ще в ньому? Це може призвести до важкої для налагодження поведінки, оскільки другий тест не розпочинається у добре відомому стані. Тоді результат тесту може залежати від порядку тестування. (Звичайно , чорний ящик тести не повинні залежати від того , чи використовуються чи ні кеша, але це цілком допустимо , щоб мати тести продуктивності , які залежать від стану кеша або , можливо , ви перевіряєте своє власне кешування Util , який використовує Ehcache під ковдрою.)
Henno Vermeulen

42

У мене була та ж проблема з моїми тестами інтеграції за допомогою JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). Проблему було вирішено за допомогою наступної конфігурації Hibernate:

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

замість використання

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

3
Я адаптував це рішення для виправлення проблем із тестуванням Spring Boot: я використовував org.hibernate.cache.ehcache.EhCacheRegionFactory замість net.sf.ehcache.hibernate.EhCacheRegionFactory для Hibernate 4 . За допомогою Spring Boot ви можете встановити це в application.properties: spring.jpa.properties.hibernate.cache.region.factory_class = org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory або за допомогою @TestPropertySource, якщо ви хочете обмежити конфігурацію тест.
Michael Koch,

1
Ого, врятував мій день після оновлення зі сплячого режиму 4.3.x до 5.2.
smallufo

22

Ваша проблема полягає в оптимізації завантаження контексту, вбудованій у тестову структуру Spring. Spring (за замовчуванням) не руйнує контекст після завершення тестового класу, сподіваючись, що інший тестовий клас може використовувати його повторно (замість того, щоб створювати його з нуля).

Ви можете замінити це значення за замовчуванням за допомогою @DirtiesContext, або якщо ви використовуєте maven, ви можете встановити для surefire forkMode значення "завжди" і створити нову віртуальну машину для кожного тестового класу.


3
Це вирішує проблему чисто для тестування середовищ, не змінюючи фактичної конфігурації виконання. Приємно!
програв

2
forkmode = завжди є гарним криком, але застарілий. див .: maven.apache.org/surefire/maven-surefire-plugin/examples/… СПРОБУЙ forkCount = 1 (за замовчуванням), reuseForks = false
theINtoy

12

Ви також можете спробувати встановити ім'я "xxx" у своїй конфігурації ehcache.xml (для елемента ehcache).

Це зробило трюк для мене, оскільки, я думаю, у мене була ще одна конфігурація кешу, яка ховається в одному з модулів мого додатка.

Спільне рішення також працює, але я не знаю далекосяжних наслідків цього.


Так! Це виявилось єдиним рішенням для мене. Додавання атрибута name до верхнього елементу echache. Здається, це не задокументовано у прикладі файлу ehcache.xml ..
Ніколас Моммаєртс

занадто сумно, що я прочитав тут лише першу відповідь, після чого повертаюся до затемнення, читаючи все джерело spring & ehcache init, щоб зрозуміти, що атрибут name потрібен, інакше файл конфігурації ігнорується ...
jpprade

хороше рішення, я отримав одне і те ж виняток із двома модульними тестами у двох різних модулях, які обидва використовували ehcache, кожен зі своїм власним файлом, і це вирішує проблему
Henno Vermeulen

Відмінно. Але я все ще не міг зрозуміти, як це може вирішити проблему, поставивши ім'я до ehcache.xml? Я використовую весняне кешування + сплячий кеш 2-го рівня. Обидва використовують один і той же файл ehcache.xml.
Санту,

1
Це рішення працює лише з конфліктуючими конфігураціями (кілька файлів ehcache.xml), якщо ви використовуєте лише одну, то це може бути іншою проблемою.
Майкл Холст

12

Після оновлення до Hibernate 5 мені довелося використовувати:

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

замість:

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

Зверніть увагу, що пакунки відрізняються один від одного.



2

якщо ви просто протестуєте свою ділову службу, а не кеш другого рівня, ви можете видалити конфігурацію другого рівня у своєму весняному конфігураційному файлі, ваш тест буде успішно запущений. є моя конфігурація другого рівня:

 <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>

якщо я перейду на повну конфігурацію конфігурації кешу другого рівня, реальний веб-додаток буде використаний під час роботи, наприклад:

    <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>

тоді я отримую той самий виняток "Інший неназваний CacheManager вже існує в тій самій ВМ"


2

У моєму випадку у нас є власний кеш-менеджер, визначений як bean. Також спеціальний контекст програми, щоб ми не використовували пробіжок spring junit ... отже, @DirtiesContext не працює.

Фокус у тому, щоб отримати екземпляр кешу з компонента, на якому кеш отримати cacheManager (екземпляр з EHCache). і на цьому кеш-менеджері викличте метод removeCache.

Помістіть це в метод, позначений @After, і ваш кеш видаляється з віртуальної машини після кожного тесту. Подобається це:

@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;
}

2

Я вирішив це, додавши до ресурсу.groovy наступне:

боб = {... aclCacheManager (EhCacheManagerFactoryBean) {shared = true} ...}


2

Це трапилося зі мною при переході на Spring Boot 2.0.2 . Вирішили це, виконавши наступне:

ВИДАЛИТИ в application.yml

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

ВИДАЛИТИ у pom.xml

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

ЗБЕРІГАЙТЕ лише у pom.xml

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

2

Установка EhCacheManagerFactoryBean#sharedдля trueпрацював для мене.

Установка EhCacheManagerFactoryBean#acceptExistingдля trueне робота для мене.

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;
    }
}

Як пояснюється у розділі Використання EhCache навесні 4 без XML


1

Для майбутніх читачів причиною цієї проблеми в моєму випадку було те, що у моєму файлі pom.xml я імпортував бібліотеку hibernate-ehcache, яка також невідомо мені також містила бібліотеку ehcache, а потім явно імпортував net.sf.ehache бібліотека.

Здавалося, це нормально працювало, коли я працював як окремий додаток (наприклад, утиліта командного рядка), але це спричинило помилку в оригінальному дописі під час роботи на сервері tomcat.

Зміна мого файлу pom з:

        <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>

Кому:

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

Виправлена ​​проблема. Якщо хтось уявляє, чому проблема з’явилася лише під час запуску в контейнері tomcat, мені було б цікаво знати ..


0

У glassfish 3.0.1 я простежив проблему, коли IniShiroFilter двічі отримував ініціалізацію, що трапляється, коли паралельні запити запускаються відразу після запуску сервера. Далі наводиться трасування стека з двох різних потоків, що відповідає двом HTTP-запитам:

[#|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)

Ще одна нитка

[#|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)

Винуватцем може бути перегляд стеку трасування ApplicationFilterConfig.java:248. Або glassfish ініціалізує фільтри в неправильному контексті, для порівняння Tomcat ініціалізує фільтри під час BootStrap.


0

У моєму випадку проблема полягає у скануванні компонентів та конфігурації Java.

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

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

spring-сканування компонентів працює двічі над файлами xml. він генерує боби всередині SpringConfig.java під час кожного запуску. тоді було створено менеджер кеш-копій.

отже, я змінив це, як нижче.

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>

0

Ця помилка також трапляється з неправильними файлами зіставлення. Повідомлення жахливе, не називає причини.


0

У моєму випадку конфігурація була такою:

<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>

Зміна класу провайдера EHCache зробила для мене роботу. Я використовував клас постачальника кешу, оскільки org.hibernate.cache.EhCacheProviderзамість цього я змінив це на: net.sf.ehcache.hibernate.SingletonEhCacheProvider


0

Станом на Spring Boot 2.1.2 наступна конфігурація працювала для вирішення проблеми. (Зверніть увагу, це фрагменти загальної конфігурації.)

Залежності:

<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:

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:

<?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>

Додаток, над яким я працюю, різко сповільнюється, не працюючи кеш. Отже, для перевірки я просто запустив додаток і натиснув одну з інтенсивних кінцевих точок читання.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.