@DirtiesContext does not restart ehcache [SPR-12687]

[spring-projects-issues]

Juraj Misur opened SPR-12687 and commented

If I use @DirtiesContext annotation together with shared (or not) ehcache instance, it does not properly reinitialize the cache, thus taking existing shutdown cache into fresh context.
See attached project.

• By running mvn test -Dshared=true 3rd test fails on
  java.lang.IllegalStateException: The strings Cache is not alive (STATUS_SHUTDOWN)
• By running mvn test -Dshared=false 2nd fails on net.sf.ehcache.CacheException: Another unnamed CacheManager already exists in the same VM

The only difference between tests is that CachebugApplication2Test have different context configuration + @DirtiesContext annotation.
If you make CachebugApplication2Test configuration the same as 1Test and 2Test, the tests succeed. Also different behavior can be observed when commenting out @DirtiesContext annotation.

The tests should run together, in order: CachebugApplication1Test , CachebugApplication2Test , CachebugApplication3Test

---

Affects: 3.2.8, 4.1.4

Attachments:

• cachebug.zip (3.97 kB)

[spring-projects-issues]

Stéphane Nicoll commented

This is working as you expected and the issue is in your project. A few explanations.

• EhCache will associate the CacheManager in a static context so you have to clean it. Fortunately, Spring finds automatically close or shutdown method on all exposed beans (or the result of the factory bean) and there is a shutdown method on CacheManager. DirtiesContext is therefore going to call that method
• Your last test does not have @DirtiesContext at all. If it run first, then it will create the static context. After that, one of the two other tests will kick in and fail because it wants to create something that is in the static context already.

You have to use @DirtiesContext everywhere you need such cleanup. If you don't well you have a chance that the static information is already present which is the case in the project you've attached.

For your information, there is a utility that allows you to build ehcache's CacheManager very easily, something like;

@Bean
public CacheManager ehCacheManager() {
	return EhCacheManagerUtils.buildCacheManager(new ClassPathResource("ehcache.xml"));
}

[spring-projects-issues]

Juraj Misur commented

Hi Stephane, thanks for quick analysis. However I'm not sure I quite agree with the behavior working as expected. I'm using spring-provided facilities, which abstract away ehcache details and implementation. Even if I comment out @DirtiesContext from CachebugApplication2Test and use shared=false, The provided tests in described order will fail, because ehcache does itself declare the cache unique per VM. The problem is not in @DirtiesContext, but in use of 2 different context configurations (1Test+3Test vs. 2Test) which both try to initialize the cache. I think this ehcache gimmick should be handled by spring, by completely erasing/resetting ehcache, since we want new context to be completely fresh. The same in scenario where cache is shared=true, but @DirtiesContext kicks in and shuts it down, and another context needs it to function.

[spring-projects-issues]

Stéphane Nicoll commented

Hi, Spring does indeed provide you a context and a way to create beans but it does not mess with what those beans are doing internally. You have tot understand that ehcache is keeping a static handle that is properly cleaned up when shutdown is being called on the cache manager. I guess we all agree that Spring couldn't know that ehCache (or any other bean) is keeping a static reference in its own internal logic.

So the problem is a combination of both. You have to use @DirtiesContext and you can't start two contexts in the same process that are trying to register the same cache manager because of some internal code in ehcache's codebase. This has nothing to do with Spring. I hope that clarifies my point.