for MaxId do you mean "select max(id) from table" ? On Wed, Feb 2, 2011 at 7:41 PM, Oskar Berggren <[email protected]>wrote:
> In other words, implementing such a "MaxId"-based generator should be > perfectly doable, but it wouldn't be HiLo of course, and it could only > use a table, not a sequence. > > /Oskar > > > 2011/2/2 Jason Dentler <[email protected]>: > > 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. > >> > > > > -- > > 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. > > > > -- > 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. > > -- Fabio Maulo -- 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.
