As I understand it, the HiLo algorithm for ID generation essentially
uses this formula:
NextID = (Hi * Lo) + (++Counter)
Hi is stored in the database, Lo is configured as part of the entity's
mapping, and the Counter is just maintained in memory within the ID
generator. Whenever Counter exceeds Lo (as new IDs are assigned to
entities), a new Hi value is fetched, and Counter is reset. Also, all
applications creating this entity basically have to use the same Lo
value to avoid potential ID collisions, given how this formula
evaluates.
What I don't understand is the advantage this would have over simply
storing a maximum ID as the Hi value, and incrementing it by the batch
size you expect to use (instead of by 1). You would still need to
fetch a new Hi value every time you run out of IDs, but there's no
need to coordinate the batch sizes across applications, or across
time.
For example, if the current Hi value is 1, an application could lock
and update that to 11 (batch size = 10), thereby safely ensuring it
can safely assign IDs 1-10. Another application could lock and update
it from 11 to 101 (batch size = 90), thereby ensuring that it can
safely assign IDs 11-100.
In either approach, locking of the Hi value in the database before
updating it is crucial. But either approach would need to do the same
number of database queries to fetch new Hi values (assuming the same
batch sizes), and a "Max ID"-style approach has the additional
flexibility of allowing the batch size to differ between applications,
or over time.
What is the advantage of HiLo here? I feel like I must be missing
something obvious.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
