Ticket #905 (closed defect: fixed)

Opened 8 months ago

Last modified 4 months ago

Locking on access to the cache could cause deadlock

Reported by: alex Assigned to: alex
Priority: critical Milestone:
Component: topaz Version: 0.8.2.2-SNAPSHOT
Keywords: deadlock OTM transaction cache Cc:
Blocking: Blocked By:

Description

We're concerned that synchronizing on a lock when accessing the cache could cause deadlock if invoked from a thread that has an open OTM transaction. If another thread attempts to access mulgara while holding the cache lock, it will wait forever for the OTM transaction. The thread with the OTM transaction will wait for the cache lock etc.

The suggested safeguard is to skip synchronization on the lock inside CacheAdminHelper?.getFromCache() and getFromCacheE() if we detect that the caller has an open OTM transaction.

We will also log an INFO level message if this occurs so we can track under which circumstances this might occur.

Dependency Graph

Change History

04/09/08 14:06:11 changed by alex

  • status changed from new to closed.
  • resolution set to fixed.

(In [5401]) Fixes #905. Prevent synchronization when accessing the cache inside an OTM transaction.

04/09/08 15:56:24 changed by russ

i upgraded, and ran browseVolume in two different tabs at the same time. i got the following: 

2008-04-09 15:48:15,706 INFO  LoggingInterceptor(PLoSNTD)> Finishing execution stack for action /article/browseVolume [http-8080-Processor24 com.opensymphony.xwork2.interceptor.LoggingInterceptor]
2008-04-09 15:48:16,061 INFO  CacheAdminHelper(PLoSNTD)> Attempted to access cache within a live OTM Transaction. Skipping synchronization on key 'IssueLock-info:doi/10.1371/issue.pntd.02' for cache 'BrowseCache' call description='issue info:doi/10.1371/issue.pntd.02' [http-8080-Processor24 org.plos.util.CacheAdminHelper]
2008-04-09 15:48:16,277 INFO  CacheAdminHelper(PLoSNTD)> Attempted to access cache within a live OTM Transaction. Skipping synchronization on key 'IssueLock-info:doi/10.1371/issue.pntd.01' for cache 'BrowseCache' call description='issue info:doi/10.1371/issue.pntd.01' [http-8080-Processor24 org.plos.util.CacheAdminHelper]
2008-04-09 15:48:16,555 INFO  CacheAdminHelper(PLoSNTD)> Attempted to access cache within a live OTM Transaction. Skipping synchronization on key 'IssueLock-info:doi/10.1371/issue.pntd.02' for cache 'BrowseCache' call description='issue info:doi/10.1371/issue.pntd.02' [http-8080-Processor24 org.plos.util.CacheAdminHelper]

i was unable to induce any contention on browseIssue

i did get a few on fetchArticle. is it odd that they are for cache BrowseCache?? does fetchArticle synchronize on keys in BrowseCache?? 

2008-04-09 15:53:41,512 INFO  CacheAdminHelper(PLoSNTD)> Attempted to access cache within a live OTM Transaction. Skipping synchronization on key 'ArticleLock-info:doi/10.1371/journal.pntd.0000104' for cache 'BrowseCache' call description='article info:doi/10.1371/journal.pntd.0000104' [http-8080-Processor25 org.plos.util.CacheAdminHelper]
2008-04-09 15:53:42,776 INFO  CacheAdminHelper(PLoSNTD)> Attempted to access cache within a live OTM Transaction. Skipping synchronization on key 'ArticleLock-info:doi/10.1371/journal.pntd.0000104' for cache 'BrowseCache' call description='article info:doi/10.1371/journal.pntd.0000104' [http-8080-Processor25 org.plos.util.CacheAdminHelper]

04/09/08 16:35:28 changed by russ

confirmed that 0.8.2.2, before this patch, does populate browse cache with an article key on fetchArticle.action

confirmed that we're still generating all keys on fetchArticle, even though we're skipping synchronization.

looks pretty good.

07/16/08 11:01:33 changed by

  • milestone deleted.

Milestone pubApp_0.8.2.2 deleted