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

[Manik Surtani (JIRA)]

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

Manik Surtani commented on JBCACHE-1449:
----------------------------------------

I am curious about the timeouts you see in MVCC.  If you can create a unit test for this, I would appreciate it.

> 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