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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
