Option to disable "local" invalidation from Cache Invalidati

[brian.stansberry]

Recently I've seen some forum postings and a support case where users complained that when they changed a commit option A entity, the CIF invalidated the entity on the local node, not just on the other nodes in the cluster. This reduced the utility of commit option A.

When I look at InvalidationManager, it seems that this behavior is what was designed. This behavior makes sense for a single JVM use case with RO and RW versions of the bean. But in a clustered use case where there is only one version of the bean per JVM, it seems less logical.

I wanted to raise on this thread the idea of adding some sort of flag to control whether invalidation events should result in local invalidations. A fairly simple approach to this would be to add a flag to InvalidationManagerMBean. This would of course be very coarse-grained. A better but more complex approach would involve adding the flag to the Invalidable interface and allowing it to be set per EJB.

Figured I'd float the idea here in case I'm missing something obvious. If others think it has any merit I'll raise a feature request in JIRA.

[starksm64]

I can't say the current behavior makes sense then. I would suspect that there has been a regression in behavior between receiving the invalidation msg locally from jgroups vs acting on that message to invalidate the local cache. I can see wanting to receive the invalidation msg locally as there could be listeners other than the entity cache, but if the listener associated with the cache receives a msg originated by the bean and its commit option A, the cache should not be invalidated. I vaguely remember losing the notion of whether or not the jgroups msg was originated locally at one point. It could be that this is the problem again as well.

[brian.stansberry]

I believe it's probably been this way since revision 1.1 of InvalidationManager. It's not due to problems handling messages from an invalidation bridge. InvalidationManager.crossDomainBatchInvalidate() itself invalidates the local cache before even calling any invalidation bridge.

[starksm64]

Hmm, ok. I guess we never really validated its behavior for commit option A then.

[adrian.brock]

It should just operate in two modes. In can operate in both concurrently.

1) Invalidate across the cluster to peer ejbs (ejbs that are essentially the same deployment).
2) Invalidate locally to related ejbs (the groups, e.g. R/W pair, the read is invalidated by the write).

It should never invalidate itself.

[adrian.brock]

It should never invalidate itself.

So any new option is irrelevant. ;-)

[brian.stansberry]

It should never invalidate itself.

So any new option is irrelevant. ;-)

Yeah, adding an option to specify whether or not to use the only rational behavior doesn't seem ideal ;-)

OK, so the idea is that if a group containing a RO bean and a RW bean (or, for that matter, any two related beans) is invalidated locally, the bean that initiated the invalidation will be excluded from the invalidation.

This means that we'd have to include in the call context information about what bean it was that actually initiated the invalidation. Then add the ability to correlate that information to the Invalidatable objects (i.e. entity caches) that are being invalidated.