Thanks Jacob. This is great. I think Hazelcast and Ignite both cache some of the results. So both of them increase the size by say 500. So till the next 500 numbers they won't be doing the comparaandSet as Jacob did.
But I guess that is manageable. This is great solution. Thanks On Mon, Jul 17, 2017 at 9:59 PM, Udo Kohlmeyer <[email protected]> wrote: > +1 @Jake, great implementation of storing the Atmoic values in a region. > > Not having much experience with Hazelcast's Atomic implementation... I > would assume this is both a server and client-side construct. > > That said, I would model the Atomics, to be persisted in a Replicate > Region on the server. In addition to that, depending on paranoia, this > could be a Replicate region with GLOBAL scope. This way the create/update > needs to lock the object within the region, over all servers, before > updating. But if you don't want to take the perf hit, DISTRIBUTED_SYNC is a > good second option. > > As for the client side implementation, a Proxy region for simple > read-through semantics. If performance is key, maybe a CACHING_PROXY region > with subscriptions enabled. This way the Atomic values are always updated > on client-side and any client atomic lookup is "local" rather than over the > wire to the server. > > --Udo > > On 7/17/17 09:09, Jacob Barrett wrote: > > There isn't anything provided by the Geode project but it is fairly easy > to implement. Having experimented with it internally some time ago it > really came down to utilizing the check and set map operations. > > Consider AtomicInteger.comparAndSet(): > public boolean compareAndSet(final Integer expect, final Integer update) > { > return region.replace(name, expect, update); > } > > Then all other operations are something like this: > public final Integer getAndIncrement() { > for (;;) { > final Integer current = get(); > if (compareAndSet(current, increment(current))) > return current; > } > } > > Keep in mind that with any compare and set type operation the more > contention for the same resource the more often it will fail meaning that > atomic inc/dec operations may loop frequently. Many round trips back to the > server could make this very expensive. > > An alternative would be to pair client side AtomicInteger with a function > on the server such that the inc/dec/set operations are sent to the server > to be resolved and the final result sent back to the client. I have not > experimented with this solution myself. > > -Jake > > > On Sun, Jul 16, 2017 at 8:16 AM Amit Pandey <[email protected]> > wrote: > >> Hi Guys, >> >> We had a hazelcast app we want to port to geode. There are some usages of >> AtomicLOng of hazelcast which we need to port, is there a best >> practice/alternative to achieve the same in Apache Geode? >> >> regards >> > >
