-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
 Post subject: 'read-write' concurrency strategy in clustered environment
PostPosted: Fri Sep 05, 2008 6:31 am 
Newbie

Joined: Fri Sep 05, 2008 6:13 am
Posts: 3
Hibernate in Action says the read-write concurrency strategy is "available only in non-clustered environments". Is this true for any cache provider because of a fundamental reason in Hibernate or is the statement just referring to those cache providers that come with Hibernate? If the former, why is this?

If possible I'd like to use the read-wite strategy with JCS cache.

Thanks,
David


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 12, 2008 12:21 am 
Newbie

Joined: Thu Sep 11, 2008 10:32 pm
Posts: 1
Similarly, the book "NHibernate in Action" also mentioned the read-write strategy "available only in non-clustered environments".

We would like to know if distributed cache provider like NHibernate.Caches.MemCache.MemCacheProvider can works with the read-write strategy or not. Thanks.

Billy


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 12, 2008 8:56 am 
Newbie

Joined: Fri Sep 05, 2008 6:13 am
Posts: 3
The JavaDoc for org.hibernate.cache.ReadWriteCache (the class that implements the read-write strategy) says this strategy may be used in a cluster, depending on the underlying cache implementation:

Quote:
If this strategy is used in a cluster, the underlying cache implementation must support distributed hard locks (which are held only momentarily). This strategy also assumes that the underlying cache implementation does not do asynchronous replication and that state has been fully replicated as soon as the lock is released.

As far as I can see, however, you could use a non-locking async cache such as EhCache as long as you accept the possibility for cache inconsistencies. If you're very cautious in choosing things to be cached (very rarely updated) the chance of an inconsistency arising would be very small. The risk can be further mitigated by configuring the cache to invalidate rather than replicate. In any case, depending on the nature of the application, inconsistencies may be acceptable. Any inconsistencies that do arise can be flushed occasionally by setting a suitable timeout (e.g. 1 hour).


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.