Thanks Jason. It seems that the two approaches I'm comparing may be what Hibernate (in Java) calls "hilo" and "pooled", added back in 2007. In "hilo", the Hi value gets incremented by 1 each time, and is multiplied by a Lo value (a batch size, basically) in order to generate an ID range. In "pooled", the Hi value simply gets incremented by the batch size, so there's no separate "Lo" to coordinate between applications/ sessionfactories.
If HiLo happened to be using a sequence internally (SequenceHiLo) *and* that sequence is only able to increment by 1, you'd be forced into something like HiLo in order to have reasonable (>1) batch sizes. But if you're using a database table to hold Hi values, or a sequence that could increment by larger amounts, you could increment by whatever amount you wanted, and thus could increment by the batch size, which can be whatever you want it to be and can change over time (which is not the case with Lo values in HiLo). So is the guess that HiLo exists as it does simply because it was implementable through the same internal algorithm (i.e., increment Hi by 1) across a variety of database platforms, whereas a simpler Pooled approach requires the capability to increment by more than 1, which was harder to guarantee could be supported? If that's the reason, then it seems HiLo doesn't have an inherent advantage aside from being implementable across a lot of platforms (which is an advantage for some, but not for me). So if my own target platform supports the simpler, more flexible "Pooled" approach I described, I'm thinking I should just implement and use that ID generation method instead. On Feb 2, 5:12 pm, Jason Dentler <[email protected]> wrote: > Here's my guess: All the hilo-style generators should use the same > algorithm. Internally, the SequenceHiLo generator uses a sequence to ensure > each sessionfactory gets its own next hi value. Therefore, the hi value must > increment by one. > > Thanks, > Jason Dentler > > > > On Wed, Feb 2, 2011 at 3:51 PM, Nick <[email protected]> wrote: > > 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]<nhusers%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en.- Hide quoted text - > > - Show quoted text - -- 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.
