In the mean you may add a JIRA ticket and then attach the implementation there. Then we can do the work to complete the integration if you don't have time to propose a patch.
On Wed, Feb 2, 2011 at 8:05 PM, Nick <[email protected]> wrote: > Agreed, "RangeAllocating" would be a better name. "Max ID" brings to > mind those terrible "select max(id) from table" implementations I've > seen before, which is not at all what I was suggesting. My poor word > choice there. > > Fabio, we're proceeding with an implementation and should be able to > share it with you when it's complete. > > Thanks for all the feedback. > > - Nick > > > On Feb 2, 5:58 pm, Nick <[email protected]> wrote: > > 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]> > <nhusers%[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 -- 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]<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.
