While you're right, it's quite possible to avoid reaching the upper limit on of the data size limit, if this is what you consider good design, then good luck to you.
John On Fri, Apr 3, 2009 at 8:34 AM, John Morales <[email protected]> wrote: > A more realistic example. > > 3 web servers 200 tables, app reseting 5 times a day > > 3 * 5 * 200 = 3000 high values a day > > the high value is multiplied by the max_lo so in just 1 year your id's will > be in the 190 billion range.. > > > While your' > > > > On Thu, Apr 2, 2009 at 9:04 PM, Erik Lundby <[email protected]> wrote: > >> <snip> >> >> . those reserved ranges are lost forever, which is wasteful >> >> </snip> >> >> >> >> But what are you wasting? With an int64 id and that default int16 max low >> you are talking about, wouldn’t you have something like 140 trillion high >> values? >> >> So if you have 100 web servers resetting 3 times an hour, you will get >> 7200 high values used a day. >> >> >> >> In 19 billion years you can probably just switch to int128. J >> >> >> >> Erik >> >> >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *John Morales >> *Sent:* Thursday, April 02, 2009 4:39 PM >> *To:* [email protected] >> *Subject:* [nhusers] Re: table hilo and application restarts/asp.net >> >> >> >> Yeah, the increment generator does not support more than 1 concurrent >> session factory per database, which right now is all I need... And I guess I >> should re-evaluate this decision, this is one of those times where YAGNI >> isn't the best strategy as I might very well need to support scaling out. >> >> IMO, the concurrent sessionfactory support hilo has using reserved blocks >> of id's is inefficient, contrary to what the documentation says. Once the >> session factory is terminated. those reserved ranges are lost forever, which >> is wasteful. With the only option is to reduce the max_lo range cap, which >> just reduces the amount of potential waste. A more efficient generator that >> reuses those unused ranges while allowing a clustered environment is what I >> truly need. >> >> If I have some time I might help out with this. >> >> John >> >> On Thu, Apr 2, 2009 at 7:03 PM, Fabio Maulo <[email protected]> wrote: >> >> 2009/4/2 John Morales <[email protected]> >> >> >> >> >> While looking into the source I saw that the increment generator does >> exactly what I need, it uses a cached copy of the max id for each table on >> appdomain start and assigns id's as necessary. Without having to hit the >> database for each insert. >> >> >> >> >> >> mmmm... take care with it... what happen when you have 2 webserver ? or >> two application instance ? >> -- >> Fabio Maulo >> >> >> >> >> >> >> -- >> This signature is intentionally left blank >> >> >> >> >> > > > -- > This signature is intentionally left blank > -- This signature is intentionally left blank --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
