[jbosscache-issues] [JBoss JIRA] Updated: (JBCACHE-1539) Combination of getChildrenNames() and getData() can lead to overwrite of child's data

Krzysztof Sobolewski (JIRA) jira-events at lists.jboss.org
Sat Sep 5 18:56:23 EDT 2009


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

Krzysztof Sobolewski updated JBCACHE-1539:
------------------------------------------

    Attachment: DataOverwriteTest.java


The test case.

> Combination of getChildrenNames() and getData() can lead to overwrite of child's data
> -------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1539
>                 URL: https://jira.jboss.org/jira/browse/JBCACHE-1539
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders, Transactions
>    Affects Versions: 3.2.0.GA
>            Reporter: Krzysztof Sobolewski
>            Assignee: Manik Surtani
>         Attachments: DataOverwriteTest.java
>
>
> [It is past midnight here and I've just finished tracking this bug...]
> The attached test illustrates the problem well. The problem is this sequence of events:
> 1) The node is in the cache store only;
> 2) A node's key is updated;
> 3) getChildrenNames() on the node's parent is called;
> 4) getData() on the node is called;
> The result of step 4 is the node's data from before modification in step 2. This results in an unpleasant situation where the write seems to get completely lost. It gets lost because it's being overwritten by the cache loader in step 4; it gets overwritten because the node's "data loaded" flag gets set to false in step 3 [1]; the flag gets set to false because the node's "created" flag is true, as returned from wrapNodeForWriting() [2]; the flag is true because the node *is* new, as it's been just loaded from cache loader in step 2. This happens only for getData() because with this command the allKeys flag in mustLoad() is true [3].
> [1] CacheLoaderInterceptor:451
> [2] CacheLoaderInterceptor:397 - invoked for each child which has "created" flag true
> [3] CacheLoaderInterceptor:433
> The reference [3] provides a workaround: instead of calling getData() you can pick the keys individually. But I'm also pretty sure the bug happens with getKeys() too.

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

        


More information about the jbosscache-issues mailing list