ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Kukushkin <kukushkinale...@gmail.com>
Subject Re: Using igniteAtomicLong or igniteAtomicSequence as uniqueId in ignite cache
Date Thu, 28 Sep 2017 09:54:44 GMT

Some thoughts that might help you to make a decision:

   - IgniteAtomicLong and IgniteAtomicSequence are both public interfaces
   but their implementations are inside the internal part of Ignite. It is a
   bad practice to reference Ignite internals so you cannot configure them in
   the XML file.
   - You create both atomic long and sequence as Ignite#atomicLong(name,
   initialValue) and Ignite#atomicSequence(name, initialValue). Thus, if you
   really want to make them Spring beans you could create an annotated spring
   configuration (@Configuration MyConfiguration { ... }) and provide factory
   methods for them (like @Bean public requestId() { return
   ignite.atomicLong("requestId", initialValue); }
   - In my opinion both the methods currently have this design flaw: even
   if you enable native persistence, you still cannot get the last sequence
   value since you are forced to provide initial value in the factory methods.
   Thus, you have to provide your custom mechanism to restore last sequence
   value after the cluster restart and pass it as initialValue if you want the
   value to be unique through the cluster restarts.
   - Please note differences between atomic long and sequence: both of them
   provide unique values but the "long" is sequential but slower and the
   "sequence" is not sequential but faster.
   - Are you sure simple Java UUID.randomUUID() will not work for you?

View raw message