[jbosscache-issues] [JBoss JIRA] Commented: (JBCACHE-1555) Mvcc node peek could contain stale data
[
https://jira.jboss.org/jira/browse/JBCACHE-1555?page=com.atlassian.jira.p...
]
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