Hi, On Wed, Nov 26, 2014 at 5:27 PM, Udara Liyanage <ud...@wso2.com> wrote:
> Reading from registry frequently might be more expensive than distributed > locking since a number of database queries are executed. > +1 for distributed collections. > > Are we going to use Hazlecast or any other framework ? > We are planning to use Carbon clustering (abstraction) which internally use Hazelcast. On Wed, Nov 26, 2014 at 5:30 PM, Akila Ravihansa Perera <raviha...@wso2.com> wrote: > >> We don't have to refresh the whole data structure, but only the > invalidated object(s). We have to have a good registry structure for the > topology in order for this to be effective. > A distributed map does this OOB. > > >> - If above happens, when serving multiple requests (with a high >> frequency) on different instances of CC, the system might come to an >> inconsistent state because the in memory data structures have not updated >> properly. >> > > Good point, thanks for pointing out. But the same problem will occur when > using cluster messages to replicate the state, right? I guess we will have > to resort to a distributed lock in either case to avoid consistencies. I > remember Isuru was working on a hierarchical locking approach for the > topology. Perhaps we can incorporate that for this scenario as well. > We actually don't use cluster messages with a distributed map. However yes in either approach we will need a distributed lock. Indeed, for topology we should be able to change the existing locks to distributed ones if clustering is enabled. > > If you're going to use a distributed map, how do you plan to utilize that > to distribute the topology data structure? I think replicating the complete > topology object on change would be very expensive, wdyt? > > No, by design it will only send the modifications. Thanks -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
