• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Duplicate
  • ehcache-web
  • lorban
  • Reporter: hhuynh
  • May 11, 2010
  • 0
  • Watchers: 0
  • July 15, 2010
  • May 11, 2010

Attachments

Description

excerpt from Chris’ email:

Whats happening is the get method in the cache
gets the Element from the store under a read lock, then when it finds
it has expired it attempts to remove it (under a write lock). Since
the BlockingCache now uses the same locks as the underlying store this
means when BlockingCache calls get on a cache with non eternal
elements, it ends up trying to do a lock upgrade since it holds the
read lock for the whole operation so it is still held when we try and
remove the expired element.

For ehcache-web this is a going to be a non-issue since Hung is moving
to using the new putIfAbsent method on the cache.

Comments

Hung Huynh 2010-05-11

attached is thread dump of a deadlock found in Weblogic

Hung Huynh 2010-05-11

Commited the fix to ehcache-web, r2424

BlockingCache has been replaced by Ehcache with the use of putIfAbsent()

Fiona OShea 2010-05-11

Try to come up with a fix that is only in BlockingCache so that the fix is backwards compatible

If you can’t come up with anything, ping Steve

Hung Huynh 2010-05-11

reverted my fix of r2424

Fiona OShea 2010-06-21

Closing as dup of linked issue