[jbosscache-issues] [JBoss JIRA] Commented: (JBCACHE-1555) Mvcc node peek could contain stale data

[Galder Zamarreno (JIRA)]

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

Galder Zamarreno commented on JBCACHE-1555:
-------------------------------------------

When writeSkew is false, it looks as if puts are being lost. For example, if you have a test where you continuously add a number to the value of an existing node, it would look as if some of those puts are not stored. That's because nodes that have locked in "Attempting to lock..." would have already peaked and might have an old value which is no longer valid by the time the lock is actually acquired.

> Mvcc node peek could contain stale data
> ---------------------------------------
>
>                 Key: JBCACHE-1555
>                 URL: https://jira.jboss.org/jira/browse/JBCACHE-1555
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Locking
>    Affects Versions: 3.2.1.GA
>            Reporter: Galder Zamarreno
>            Assignee: Manik Surtani
>            Priority: Critical
>             Fix For: 3.3.0.GA
>
>         Attachments: Chtimi2Test.java, jbosscache.log, logging-changes.txt
>
>
> I've added some extra logging to the attached test case to find out where the problem is:
> 2009-11-06 19:37:52,762 1064  DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-1:) Peek internal node for fqn /foo/mynode
> 2009-11-06 19:37:52,763 1065  DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-1:) Peek returned UnversionedNode[ /foo/mynode data=[scalar]]@14e45b3
> 2009-11-06 19:37:52,763 1065  TRACE [org.jboss.cache.lock.MVCCLockManager] (pool-1-thread-1:) Attempting to lock /foo/mynode
> ...
> 2009-11-06 19:37:52,763 1065  TRACE [org.jboss.cache.commands.write.PutKeyValueCommand] (pool-1-thread-1:) Perform('GlobalTransaction:<null>:3', '/foo/mynode', k='_lockthisplease_', v='_lockthisplease_')
> ...
> 2009-11-06 19:37:52,767 1069  DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-5:) Peek internal node for fqn /foo/mynode
> 2009-11-06 19:37:52,767 1069  DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-5:) Peek returned UnversionedNode[ /foo/mynode data=[scalar]]@14e45b3
> 2009-11-06 19:37:52,767 1069  TRACE [org.jboss.cache.lock.MVCCLockManager] (pool-1-thread-5:) Attempting to lock /foo/mynode
> ...
> 2009-11-06 19:37:52,774 1076  TRACE [org.jboss.cache.lock.MVCCLockManager] (pool-1-thread-1:) Attempting to unlock /foo/mynode
> ...
> 2009-11-06 19:37:52,777 1079  DEBUG [org.jboss.cache.mvcc.RepeatableReadNode] (pool-1-thread-5:) underlyingNode is UnversionedNode[ /foo/mynode data=[scalar, _lockthisplease_]]@fa39d7
> 2009-11-06 19:37:52,777 1079  DEBUG [org.jboss.cache.mvcc.RepeatableReadNode] (pool-1-thread-5:) node is UnversionedNode[ /foo/mynode data=[scalar]]@14e45b3
> 2009-11-06 19:37:52,778 1080  WARN  [org.jboss.cache.mvcc.RepeatableReadNode] (pool-1-thread-5:) Detected write skew on Fqn [/foo/mynode].  Another process has changed the node since we last read it!.  Unable to copy node for update.
> pool-1-thread-5 has peeked too early! it was waiting for lock that pool-1-thread-1 one and carried with old data. In the mean time, pool-1-thread-1 wrote the data and unlocked which allowed pool-1-thread-5 to continue but it had cached data that is now stale.

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