• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • alexsnaps
  • Reporter: ihrytsyuk
  • September 24, 2010
  • 0
  • Watchers: 2
  • October 19, 2010
  • September 30, 2010



Lets consider next example: * Thread-1 requests element by key-1 from a cache. The Element doesn’t exist in the cache. It takes 30 sec to calculate element. * Several milliseconds later Thread-2 requests element by key-2 from the cache. The Element exists in the cache. * CompoundStore#getSyncForKey(Object key) returns the same Sync for key-1 and key-2 from method. So Thread-2 will wait for 30 sec until Thread-1 is calculating its element. But Thread-2’s element is already in the cache and must be returned asap.

In ehcache-core-2.0.1 we were able to pass number of mutexes (a.k.a numberOfStripes) to BlockingCache constructor to decrease probability of mentioned scenario. In ehcache-core-2.2.0 we also can pass a numberOfStripes to constructor, but actually default number of mutexes (64) is used. As result, we can have unreasonable delays.

Test application is attached. It shows mentioned scenario and is maven2-ready.


Fiona OShea 2010-09-29

Alex, does this look like a regression? Assigning to Magnum to get a quick answer:)

Alexander Snaps 2010-09-30

reverted to StripedReadWriteLockSync for standalone blocking cache