Is cache Invalidation possible under ...

[haseen]

We are using session facade in our application where only SLSBs are avaliable remotely. Our BMP entity beans are local objects only.

We are planning to intriduce clustering. Is it possible that our application is deployed at cluster level overall but the entity beans are not replicated when created at one node. Also we want to introduce Cache invalidation, in case same instance of Entity beans exists at two different nodes (created by two different users at two different nodes).

That is if same entity exists at two different nodes not by cluster replication, but by client access and one of them changed, can we use Cache Invalidation under this scenario.


For example can I add the folloiwng in jboss.xml


<ejb-name>nextgen.EnterpriseEntity</ejb-name>
<jndi-name>nextgen.EnterpriseEntity</jndi-name>
<configuration-name
>Standard CMP 2.x with cache invalidation<
/configuration-name>
<method-attributes>

<method-name>get*</method-name>
<read-only>true</read-only>

<method-attributes>
<cache-invalidation>True</cache-invalidation>

<!-- No Cluster-Config etc. -->





Thanks,

Amin

[brian.stansberry]

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.

[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

[brian.stansberry]

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.

[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

[brian.stansberry]

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.

[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?

[brian.stansberry]

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]