Re: [jgroups-dev] Design of a cluster wide atomic counter
Galder ZamarreƱo <[email protected]> Fri, 7 Oct 2011 18:10:24 +0200
| Newsgroups | gmane.comp.java.javagroups.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sep 29, 2011, at 11:24 PM, balrog of moria wrote: > > > ---------- Forwarded message ---------- > From: balrog of moria <[email protected]> > Date: Thu, Sep 29, 2011 at 11:24 PM > Subject: Re: [jgroups-dev] Design of a cluster wide atomic counter > To: Bela Ban <[email protected]> > > > A unique id generator is nice, but a clustered atomic counter can be very useful. A nice Hibernate versioning counter for instance without relying on a 2nd level cache, just a counter. AtomicLongs would suffice, you can always write them as variable length longs on the wire. To be honest I wouldn't mind tweaking it for some sort of JGroups NTP emulator (I need millisecond precision and regular system NTP syncs are sometimes not enough), although the problem is more difficult since the time for a round trip would need to be considered. Clarification: Hibernate 2LC generates no versions, they come from the database. > > My 0.02 cents > > Nicolas > > > On Thu, Sep 29, 2011 at 10:30 PM, Bela Ban <[email protected]> wrote: > I'm designing a cluster wide counter, see [1] for details. This is a > service which provides a cluster wide named counter, with methods get(), > set(), incrementAndGet(), decrementAndGet() and compareAndSet(), similar > to AtomicInteger. > > So if 2 threads have a reference to a named counter "x", then each > calling incrementAndGet() on it will ensure that they get unique values. > > This was suggested by Sanne, who needs something like this in Lucene, > but I also want to make it as generic as possible. > > So I'm wondering if > - these methods make sense at all, or if all we want is only really a > unique ID generator > - whether we need an int or a long, or both as counter > - whether there are other use cases for an atomic cluster wide counter > > Your feedback and 5 cents is appreciated ! > > > [1] > https://github.com/belaban/JGroups/blob/JGRP-1366/doc/design/CounterService.txt > > -- > Bela Ban > Lead JGroups (http://www.jgroups.org) > JBoss / Red Hat > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Javagroups-development mailing list > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1_______________________________________________ > Javagroups-development mailing list > -- Galder ZamarreƱo Sr. Software Engineer Infinispan, JBoss Cache ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Javagroups-development mailing list