[jbosscache-issues] [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
Galder Zamarreno (JIRA)
jira-events at lists.jboss.org
Thu Sep 17 05:56:23 EDT 2009
[ https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Galder Zamarreno updated JBCACHE-1544:
--------------------------------------
Attachment: patch-v1.txt
jboss-cache-jdk50.jar
I've got a potential one liner fix for this:
Index: src/org/jboss/cache/TreeCache.java
===================================================================
--- src/org/jboss/cache/TreeCache.java (revision 8231)
+++ src/org/jboss/cache/TreeCache.java (working copy)
@@ -5105,7 +5105,7 @@
boolean eviction = true;
if (log.isTraceEnabled())
log.trace("_evict(" + fqn + ")");
- if (hasChild(fqn))
+ if (hasChild(fqn) || isNodeLockingOptimistic())
{
_removeData(null, fqn, create_undo_ops, sendNodeEvent, eviction);
return false;
Basically, if optimistic, never evict the whole node, but just delete the data. This will leave the version hanging around which makes the test in the patch pass.
I'm uploading a jboss-cache-jdk50.jar containing this patch.
> Optimistic locking and eviction
> -------------------------------
>
> Key: JBCACHE-1544
> URL: https://jira.jboss.org/jira/browse/JBCACHE-1544
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.4.1.SP13
> Reporter: Mircea Markus
> Assignee: Galder Zamarreno
> Attachments: cluster-evictor.tar.gz, jboss-cache-jdk50.jar, optimistic-replicated-eviction.xml, OptimisticReplicatedEvictionTest.java, patch-v1.txt
>
>
> Since eviction is done per node, it is easy to get the cache into a bad
> state. For example, a 2-node cluster, OPTIMISTIC, REPL_SYNC, 60 second
> eviction:
> On Node A:
> cache.put ( "/foo", 0, 0 ); // this could be from any node
> for ( ;; ) {
> Thread.sleep ( 30000 ); // wait 30 seconds
> cache.get ( "/foo", 0 ); // refresh the eviction timer so the node will
> never be evicted on A
> }
> ---------
> This is just using the default JBC versioning, and direct cache access.
> No hibernate.
> There's no special configuration for the cache except what I listed
> (OPTIMISTIC, REPL_SYNC, 60 second
> eviction). No code hitting the cache except what I listed below.
> By the way, this is EAP 4.3 CP05 (JBC 1.4.1.SP13).
> On Node B:
> // wait at least 60 seconds after the original put for the node to be
> evicted on B
> cache.put ( "/foo", 0, 0 ); // will always fail during replication to A:
> org.jboss.cache.optimistic.DataVersioningException: DataNode [/foo]
> version Ver=2 is newer than workspace node Ver=1
--
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