New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
possibility to initialize the id-generator with a start-id #11
Comments
I also think that the Distributed Id of Hazelcast should offer the possiblity to set the initial value. In a distributed system, it would be much better to use the Hazelcast distributed Id instead of the Database generated id. The only issue of Hazelcast distributed id is that once the whole cluster is restarted, we cannot use the distributed id anymore as the ID will start from 0. |
Implemented in 3.0. |
I am looking for the code related to this - can someone help me figure out where this feature exists in 3.0 and how to use it? |
you can see init method here https://github.com/hazelcast/hazelcast/blob/v3.0/hazelcast/src/main/java/com/hazelcast/core/IdGenerator.java |
update tomcat session replication readme file
Bugfix kubernetes via dns
Update to version 3.11
Add META-INF file
The docs say that the cluster-wide id-generator starts at 0 again, if the
whole cluster is restarted.
I miss the possibility to set the starting id (other than 0).
I use an IMap with a MapLoader/MapStore impl. and store the entries in a
MySql DB. With write-behind cache I cant rely on the DB's auto-generated IDs.
So I was glad when I saw your id-genrator. But I need to make sure I wont
get duplicate IDs after all cluster nodes have been gone, which could
happen during a server update/downtime etc. My idea was to get the last
used ID from DB and tell the hazelcast generator to start from there.
Migrated from http://code.google.com/p/hazelcast/issues/detail?id=256
earlier comments
lajos.kesik said, at 2010-12-29T18:04:34.000Z:
It could be an automatic mechanism. At cluster start hazelcast should read the last value from a place where it is stored. Eg: Last value can be stored in a database. Storage could happen at every MapStore operation so there is no overhead at increment time. Eg.: MapStore, MapLoader could have an additional method to store and read the last id value. Load method can be used at cluster start to get the last value of the Id.
debersom@murashige.com.br said, at 2011-12-29T03:20:20.000Z:
I implemented a method to initialize the values of IdGenerator, this method receive as parameter a map with initial value by range and can be initialized in the method loadAllKeys of MapLoader. I.E. retrieves the values to put on map with the query: SELECT (ID / 1000000) as RANGE_ID, MAX(ID) AS LAST_ID FROM ENTITY GROUP BY (ID / 1000000) then create the map and initialize the IdGenerator.
The text was updated successfully, but these errors were encountered: