[jbosscache-issues] [JBoss JIRA] Commented: (JBCACHE-1449) Small lock confusion in CacheLoaderInterceptor

[Krzysztof Sobolewski (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBCACHE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12441624#action_12441624 ] 

Krzysztof Sobolewski commented on JBCACHE-1449:
-----------------------------------------------

I'm not sure a unit test is possible (or feasible) because it's not deterministic. Maybe it could be possible with specially crafted listeners that pause two threads at exactly the right moments (I've done this before) but that would be some work :)
I haven't tested with 3.x due to lack of time (today, at least). I only looked briefly at the version of this class from trunk and it doesn't look affected (no locks at all?).

> 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
>             Fix For: 3.1.0
>
>
> 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