Discussion thread for
http://jira.jboss.com/jira/browse/JBCACHE-1303.
I think the essence of the issue here is the cache has no mechanism for doing a rollback
of an invalidation. So, if you send out a set of invalidations as part of a PREPARE call,
there is no way to undo them with a subsequent ROLLBACK.
With PL, this is less of an issue, since even if you don't roll back the invalidation
on the other nodes, the cluster remains in a "consistent" state per the
invalidation-semantics. That is, for a given FQN, every node in the cluster either has
that node with the same state, or doesn't have the node. This is why I say in point
#2 in the JIRA description that it's less of an issue. At least that's what I
think; comments welcome. :)
For OL, the problem is harder since the invalidation changes the DataVersion of the
"tombstone" node. Here, some sort of rollback is needed. Perhaps though it is
sufficient to restore the data version to the "tombstone" in the rollback
operation.
A side benefit of fixing this is invalidation currently doesn't batch the invalidation
messages for a tx. So, if you change 10 nodes in a tx, as part of tx commit JBC sends out
10 invalidation messages. Using a normal PREPARE would eliminate that.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133684#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...