Re: [jgroups-dev] Design of a cluster wide atomic counter

On 9/29/11 11:24 PM, balrog of moria wrote:

> 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.


Is a versioning counter a monotonically increasing ID ? Or just a unique 
ID generator ?

The main point for this was that UUIDs took up too much space in memory, 
so a counter should be smaller...


>  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.


Yes. I prefer the centralized approach of getting an ID, as it has a 
constant cost regardless of the cluster size. To ease the burden on the 
coordinator, I'm thinking to even have different owners for named 
counters, e.g. based on the consistent hash of the counter name. This 
maybe in a next step; I need to get detailed requirements first.
Cheers,

-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat

------------------------------------------------------------------------------
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