[jbosscache-issues] [JBoss JIRA] Updated: (JBCACHE-1479) Loads nodes from cache loader too aggresively

Tue Feb 17 09:35:45 EST 2009

     [ https://jira.jboss.org/jira/browse/JBCACHE-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Krzysztof Sobolewski updated JBCACHE-1479:
------------------------------------------

    Attachment: ConcurrentReadsDeadlockTest.java

Here's a "working" test that exhibits the deadlock. The crucial element is the cache loader config - if I take it out, the deadlock disappears (as can be expected).
I included two iterations because I mistakenly believed that it happened only on the second pass, but it doesn't ;)

I will also attach a version for 2.2 branch that doesn't deadlock.

> Loads nodes from cache loader too aggresively
> ---------------------------------------------
>
>                 Key: JBCACHE-1479
>                 URL: https://jira.jboss.org/jira/browse/JBCACHE-1479
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders, Transactions
>    Affects Versions: 3.0.2.GA, 3.1.0.GA
>            Reporter: Krzysztof Sobolewski
>            Assignee: Manik Surtani
>         Attachments: ConcurrentReadsDeadlockTest.java, ConcurrentReadsDeadlockTest.java
>
>
> I have a test that goes like this (all in the same thread):
> 0. populate cache with a single node, via a simple put().
> 1a. start transaction 1 (and suspend)
> 1b. start transaction 2 (and suspend)
> 2a. resume tx1
> 2b. get the node
> 2c. suspend tx1
> 3a. resume tx2
> 3b. get the node
> 3c. suspend tx2
> 4. resume and end both transactions
> With 2.2 it works fine. With 3.x (3.0.2 and trunk) it timeouts on step 3b. The problem is that even though the node was added by me and was not evicted, the CacheLoaderInterceptor tries to load it for both transactions (steps 2b and 3b). This entails a write lock, hence a deadlock. From what I gather this is because the "data loaded" flag is never set on the node and it confuses the interceptor, which tries to load (and puts a write lock) on each and every access. My guess is that the flag should be set to true after put() -- if I do it "by hand", there is no deadlock (but then some other test fails, which means that I'm not qualified to fix this problem :) )

-- 
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