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.