Small lock confusion in CacheLoaderInterceptor ---------------------------------------------- Key: JBCACHE-1449 URL: https://jira.jboss.org/jira/browse/JBCACHE-1449 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani I was doing another torture-test of one of my components based on JBoss Cache and noticed mysterious "can't lock node" exceptions. The test is very simple: 5 threads are trying to retrieve one node's key, 5 other threads try to delete it. Long story short, I think the result is one the smallest fixed I've ever seen :) Index: src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java =================================================================== --- src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (revision 6986) +++ src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (working copy) @@ -245,7 +245,7 @@ { NodeSPI n = dataContainer.peek(fqn, true, true); Object lockOwner = lockManager.getLockOwner(ctx); - boolean needLock = n != null && !lockManager.ownsLock(fqn, lockOwner); + boolean needLock = n != null && !lockManager.ownsLock(n, lockOwner); boolean mustLoad = false; try { It seems that when the node (n) is deleted, the lockManager checks some different nodes map, when it uses the node's FQN, than is later checked on line 252, where it tries to read-lock the node (and fails, because it's already locked by pessimistic locking interceptor). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira