-
1. Re: Is cache Invalidation possible under ...
brian.stansberry Feb 3, 2006 1:42 PM (in response to haseen)Yes, you can mark beans for clustered invalidation without adding a cluster-config. See page 93 of the clustering guide http://docs.jboss.org/jbossas/clustering/JBossClustering7.pdf; your proposed config is basically what's shown :)
BTW, EJB 2.1 entity beans are not replicated. -
2. Re: Is cache Invalidation possible under ...
haseen Feb 4, 2006 12:15 PM (in response to haseen)Thanks for the response.
Just to clarify,
Since we are using BMPs (2.?), we will be using "Standard BMP EntityBean" in our JBoss.xml and there is not other "interceptor" attribute needed.
- Haseen -
3. Re: Is cache Invalidation possible under ...
brian.stansberry Feb 5, 2006 1:55 AM (in response to haseen)Sorry, missed the bit in your original question where you said you were using BMP.
So, no, you're going to need to create your own container configuration, based on the "Standard BMP Entity Bean" and adding the interceptor and changing the instance cache, as described in pages 90-92 of the clustering guide. -
4. Re: Is cache Invalidation possible under ...
haseen Feb 8, 2006 1:40 PM (in response to haseen)Thanks for your response.
I have created a new container configuration as you have suggested "Standard BMP 2.x EntityBean with cache invalidation" on the same lines as described in the guide.
Here is my configuration :
1. Session beans are clustered and the policy is "FirstAvailable".
2. BMP Entity beans are not clustered but are set for cache invalidation.
The problem is after business method, even the bean object from the current node is invalidated.
I am using Commit Option A and I want the "just used bean object" to be valid on the last accessed node while invalidated on other nodes.
What am I missing here?
Thanks,
Haseen -
5. Re: Is cache Invalidation possible under ...
brian.stansberry Feb 19, 2006 1:24 AM (in response to haseen)Sorry to take so long to reply -- I've been struggling to get a moment to look into this.
You're not missing anything; it seems the InvalidationManager invalidates the local cache whenever it processes an invalidation event.
This behavior is necessary in one of the use cases for the cache invalidation framework, "Single JVM RO/RW Bean", where two versions of the same entity bean are deployed, one read-only, one read-write. (See Clustering docs for more on this usage.) This behavior ensures the RO bean will be invalidated after any update to the RW bean.
Unfortunately, this behavior makes commit option A less useful in the more common CIF use case, invalidating remote caches of a clustered entity.
I've opened a design discussion thread re: adding a config option to turn off the local cache invalidation. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77697. -
6. Re: Is cache Invalidation possible under ...
haseen Feb 19, 2006 9:56 PM (in response to haseen)Thanks for the response.
I didn't understand what does Adrin mean by "Any new option is irrelevent".
So what is the next step now? -
7. Re: Is cache Invalidation possible under ...
brian.stansberry Feb 22, 2006 8:47 PM (in response to haseen)The next step on this my raising this JIRA issue: http://jira.jboss.com/jira/browse/JBAS-2837
At this point I can make no promises as to when this will be fixed; we'll have to weigh its significance against other priorities. You can of course vote for the issue.[/url]