Unfortunate, then it's a balancing act of what is a low enough max_lo that your comfortable skipping ranges of ids.
On a side note, It seems that setting the table param on each hilo will allow each table to have a separate hi value, which will reduce the id size growth to the amounts of restarts instead of amount of restarts * amount of tables, which is the default if you use hibernate_unique_key. Seems like unless you don't care about id's scalling out of control, hilo is not an ideal choice for asp.net applications since applications are expected to recycle often, unless the application pool is changed not to restart.. 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. Thanks Tuna. On Thu, Apr 2, 2009 at 11:25 AM, Tuna Toksoz <[email protected]> wrote: > You can use lower maxLo value, or another identity strategy. > > > > Tuna Toksöz > Eternal sunshine of the open source mind. > > http://devlicio.us/blogs/tuna_toksoz > http://tunatoksoz.com > http://twitter.com/tehlike > > > > > > On Thu, Apr 2, 2009 at 4:52 PM, John Morales <[email protected]> wrote: > >> I'm noticing a scalability issue with hilo and my web application. Every >> time the asp.net application restarts the app domain, the hilo generator >> uses a new set of hi values, not exhausting the previous set. This is >> causing fragmentation in the ids since the algorithm is more or less: >> >> hi * (maxLo + 1) + hi + lo >> >> Using the default maxlo of Int16.MaxValue and assuming a simplified >> application with just one table, I get the following: (Application restarts >> are simulated, but in ASP.NET the default is 20 minutes of inactivity, >> IIRC) >> >> Table 1 >> ====== >> 32768 >> 32769 >> 32770 >> <Application Restart> >> 65536 >> 65537 >> 65538 >> <Application Restart> >> 98304 >> 98305 >> >> >> I understand why this is happening and I don't need support for multiple >> concurrent session factories. I read in a previous thread, talk about >> keeping the current max hi for each table, that might help but ideally the >> generator would restart the hilo assignment where it left off. i.e. >> >> per each table... >> get old hi value >> get last lo value in db. >> check >> if lo < maxLo >> current hi >> else get new hi. >> >> >> Have you guys faced this before, is it not an issue to burn through and >> fragment these ids? >> >> I rather not set the application pool not to restart, but I guess I could, >> MS says it's good practice to have application restart triggers on memory >> and time limits for asp.net applications. >> >> >> >> -- >> 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 -~----------~----~----~----~------~----~------~--~---
