-
1. Re: Clustering and commit options
juha Sep 26, 2003 5:19 AM (in response to brendanl)You need to use B/C.
-- Juha -
2. Re: Clustering and commit options
juha Sep 26, 2003 5:20 AM (in response to brendanl)Distributed cache will be in 4.0
-- Juha -
3. Re: Clustering and commit options
brendanl Sep 29, 2003 2:45 AM (in response to 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? -
4. Re: Clustering and commit options
juha Sep 30, 2003 4:52 AM (in response to brendanl)Clustering will be less performant in almost all scenarios compared to single node fully cached version (commit option A).
-- Juha -
5. Re: Clustering and commit options
nraghuram Oct 3, 2003 7:09 AM (in response to brendanl)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 -
6. Re: Clustering and commit options
senthilcool Oct 3, 2003 12:42 PM (in response to brendanl)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. -
7. Re: Clustering and commit options
juha Oct 3, 2003 9:42 PM (in response to brendanl)> But will the concept of cache invalidation groups be
> applicable on a cluster
Yes. Check the invalidation bridges in clustering documentation.
-- Juha -
8. Re: Clustering and commit options
nraghuram Oct 6, 2003 12:22 AM (in response to brendanl)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 -
9. Re: Clustering and commit options
juha Oct 6, 2003 5:41 AM (in response to brendanl)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 -
10. Re: Clustering and commit options
nraghuram Oct 6, 2003 11:23 PM (in response to brendanl)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 -
11. Re: Clustering and commit options
juha Oct 7, 2003 3:25 PM (in response to brendanl)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 -
12. Re: Clustering and commit options
senthilcool Oct 7, 2003 7:09 PM (in response to brendanl)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 -
13. Re: Clustering and commit options
nraghuram Oct 7, 2003 10:59 PM (in response to brendanl)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 -
14. Re: Clustering and commit options
juha Oct 10, 2003 11:29 AM (in response to brendanl)> 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