Clustering and commit options

[brendanl]

Hi,
If I cluster a number of JBoss instances, all of which point to one database, am I obliged to use a commit option (like C?) that does not cache between transactions? Or does EJB clustering synchronize Entity Beans to maintain the cached entity beans?

TIA,

Brendan.

[juha]

You need to use B/C.

-- Juha

[juha]

Distributed cache will be in 4.0

-- Juha

[brendanl]

Thanks for that. Do you happen to know of any resources that give guideline statistics on clustering?

I ask, because it seems that for systems that normally use commit option A, there is the possibility that clustering will be less performant (at least up to a certain number of users).

Clearly clustering will still have a use in providing failover.

What are the scaleability options for commit option A systems, I wonder?

[juha]

Clustering will be less performant in almost all scenarios compared to single node fully cached version (commit option A).

-- Juha

[nraghuram]

I am using a cache invalidation with Read Mostly pattern on a single machine. I want to use the same combination on a cluster.
But will the concept of cache invalidation groups be applicable on a cluster i.e if i have deployed the entity twice on each node - one as EntityRO and one as EntityRW, if I perform an update on EntityRW on any one of the nodes then the EntityRO on all nodes get invalidated.
thanks
raghu

[senthilcool]

I am trying to so the same thing. But I can't get the cache invalidation to work within a single node. My RO entity seems to do an ejbLoad() (query to db) for every query. It does not seem to be caching even though there have ben no changes. Pls take a look at the attached jboss.xml file and let me know what is wrong. If I make the RO bean read-only or all the getters read-only, the cache is never invalidated even if there are changes made using the RW bean.
Any help will be really appreciated.

[juha]

> But will the concept of cache invalidation groups be
> applicable on a cluster

Yes. Check the invalidation bridges in clustering documentation.

-- Juha

[nraghuram]

Juha,
thanks for the reply. A related question.
Are the invalidation messages sent by the manager acknowledged by the listeners. Is it possible that the invalidation message fails to get delivered , in which case we have an inconsistent cache across the cluster.
thanks
raghu

[juha]

The invalidation service is not transactional so it is possible to have inconsistency even without failure. If your application requires 100% consistency in all scenarios you cannot use cache, period. Commit option B/C is then your only option.

-- Juha

[nraghuram]

Hi Juha,
Could you explain what you mean when you say the cache is not transactional please.
I know that there is no distributed locking, but I can get around that by delegating locking to the database.
I need the cache entry to get invalidated if an update happens anywhere on the cluster, reliably.
As per my understanding, if invalidation happens reliably, the inconsistency in the cache is there for the period between the update on a node and the invalidation across the cluster.
I am using B/C with IPT for all my writable entities but my read only entities use option A with invalidation.
Would appreciate if you clarified what you mean
thanks
raghu

[juha]

I mean there's no atomicity in the cache invalidation. For a short period of time, a node A in your cluster may return a cached data even though the values were updated in the database -- in case the invalidation messages have not reached the target node yet.

If you cannot afford this chance of inconsistency at all, then you will need to use B/C on all nodes.

That is until you get 4.0 with distributed cache.

-- Juha

[senthilcool]

Hi Juha,

Does the cache invalidation framework expose any API's that can be called from the code to invalidate entities of a particular identity and cache group on-demand?

Is the distributed cache in 4.0 transactional, ie. does it guarantee that all entities across all nodes will always be up-to-date? Is there any documentation available about how it works ?

Thanks for the help.

cheers,
senthil

[nraghuram]

Thanks Juha. I agree with the potential inconsistency. My concern was also whether message acknowledgment is built in and if a target node fails to receive a message, whether it is resent. Am not sure if that happens in the 3.2 releases.
thanks
raghu

[juha]

> Is the distributed cache in 4.0 transactional, ie.
> does it guarantee that all entities across all nodes
> will always be up-to-date?

Yes.

> Is there any documentation available about how it
> works ?

http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop