Why not always use cache invalidation option?

[anarvekar]

I have a question regarding the 'Standard CMP 2.x EntityBean with cache invalidation' container configuration vs. 'Standard CMP 2.x EntityBean'. I know what both of these do. My question is this. When would I ever want to use 'Standard CMP 2.x EntityBean' because 'Standard CMP 2.x EntityBean with cache invalidation' seems to give me the benefits of commit option A when I am in a single server mode and in a clustered environment it gives me the benefit of keeping the entity beans in sync by invalidating the cache on the other servers.

Wouldn't you always want to use the cache invalidation option regardless of whether you are in a single-server or clustered setup? This is of course based on my assumption that in a single-server setup, the cache for the single server will not be invalidated (that would lose the benefit of commit option A). What am I missing here?

Thanks.
Ashish.

[brian.stansberry]

On a single server, concurrent access to an individual bean is controlled via locking of the bean itself. There is no need to invalidate the cache, because while one transaction has the bean locked, it is not readable by other transactions.

[anarvekar]

Thanks for the reply.

So, does that mean that when you have cache invalidation option on, even in a single-server mode, the cache will be invalidated. I thought that there would be a distinction made between a cache on a remote server and cache on a local server. i.e., in a single-server mode, since the cache is local, it would not be invalidated. In other words, this would be just like the commit A option without cache invalidation. I tried to validate this with some load tests but they were not that conclusive. Let me know if I am wrong with my assumption.

Thanks.
Ashish.

[brian.stansberry]

Yes, it will be invalidated even on the local server. :( That's a bug, see http://jira.jboss.com/jira/browse/JBAS-2837