[jbosscache-issues] [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1544:
--------------------------------------
Attachment: OptimisticReplicatedEvictionTest.java
I'm attaching a unit test I've created to jira. I'll be uploading the config
file too.
I haven't looked at this in depth but an idea that comes to my mind is potentially
keeping version information around in spite of eviction. This would be slightly similar to
what happens with queries and timestamps in the 2nd level cache world. You need the
timestamps not to be evicted otherwise queries would resolve in the cache even though
entities have been evicted, leading to wrong query results.
Another (rather crazy) idea would be evictions to result on cluster wide removals cos that
would clear the version information everywhere. This might be a reasonably easy
workaround, could be implemented relatively easily with a Cache listener. I believe Jimmy
W had someone asking him for evictions to result in cluster wide removals. It'd be
interesting to find out whether something came out of that cos it'd potentially be
useful here.
I'll have a further think overnight and see if I can come up with more ideas.
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: optimistic-replicated-eviction.xml,
OptimisticReplicatedEvictionTest.java
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