"so we end up creating a new SessionFactory on each invocation" Azure Functions supports static variables.
2017-10-27 23:00 GMT+02:00 Nicholas Piasecki <[email protected]>: > I ran into this today as well on Azure Functions with NH 4.1.1.4000. It > doesn't seem to happen on my older apps still on NH 3.x, mainly because > this alias length check is not there. > > Azure Functions doesn't really have the concept of host-level startup and > shut down (they are supposed to be "run-once" and stateless, though this > leaks out from time to time), so we end up creating a new SessionFactory on > each invocation. Perusing the NHibernate source, it looks like there's a > ThreadStatic tableCounter variable that is incremented when the constructor > for the Table class is called. Wonderful. > > Suspecting this may have something to do with it, I wrote a console app > that iterated through creating 100 session factories and watching the > queries it produced in NHProf, and sure enough the aliases get longer and > longer because uniqueInteger climbs higher and higher. Then you explode at > some point because the alias is too long. > > Even the Azure Functions like you to pretend that you're running > stateless, there is still a host process, and the threads that you run on > may get recycled. So if you keep creating SessionFactory instances over and > over -- which you aren't supposed to do, and typically don't in a typical > web app, but you end up doing in a serverless framework like Azure > Functions -- you will get this climbing alias length. > > Subclassing MsSql2012Dialect in my case and setting MaxAliasLength to 128 > works as a temporary band-aid. But the real workaround is to just stop > instancing so many SessionFactories. I moved it to a static variable to > ensure that it's only instanced once, even though my Autofac container is > getting rebuilt every time Azure Functions invokes my code. I hope this > helps someone. > > Nicholas Piasecki > > On Thursday, July 13, 2017 at 7:03:35 AM UTC-4, Alex Bunn wrote: >> >> Bit of an update. >> >> After a further bit of researching, we came across NH-3899 >> <https://nhibernate.jira.com/browse/NH-3899>. While its not our error >> (Fixed in 4.1, we're currently using 4.1.1.4000), its the commits made to >> fix this error that seem to be causing our error. >> >> There was 1 commit >> <https://github.com/nhibernate/nhibernate-core/commit/013b5da27301adc1fab6a95d9c164d27d1eae03d> >> made to update the code to its current Hibernate >> <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/mapping/Column.java> >> counterpart, but another commit >> <https://github.com/nhibernate/nhibernate-core/commit/16fafd1c086257d5c72946e863a90a3433529c7f> >> was made almost immediately after to prevent the alias name from becoming >> too long, in particular the changes made to the overloaded method ' >> GetAlias(Dialect.Dialect dialect, Table table)' which is being >> referenced in our stacktraces when this error occurs. Furthermore the >> changes made in this commit don't appear to be based off the original >> Hibernate code (and neither does the original code have these changes), so >> it has us questioning whether or not this is correct behaviour. >> >> Relevant lines from the raised error. >> >> System.Exception: Error trying to resolve Service >> 'TechCertain.Web.UI.Controllers.HomeController' or one of its autowired >> dependencies (see inner exception for details). ---> System.Exception: Error >> trying to resolve Service 'TechCertain.Domain.Interfaces.IUserRepository' or >> one of its autowired dependencies (see inner exception for details). ---> >> SimpleInjector.ActivationException: The registered delegate for type >> ISessionFactory threw an exception. Unique suffix 10_ length must be less >> than maximum 3 characters. ---> NHibernate.MappingException: Unique suffix >> 10_ length must be less than maximum 3 characters. >> at NHibernate.Mapping.Column.GetAlias (Int32 maxAliasLength) <0x41529310 + >> 0x00219> in <filename unknown>:0 >> at NHibernate.Mapping.Column.GetAlias (NHibernate.Dialect.Dialect dialect, >> NHibernate.Mapping.Table table) <0x41529240 + 0x0008d> in <filename >> unknown>:0 >> >> >> At this stage we're not sure how to proceed. The Stackoverflow >> recommended solution <https://stackoverflow.com/a/39047655> is to create >> a custom class and override the 'MaxAliasLength' property, but we've >> tried this without success (Nibernate fails to load the class). The only >> other >> option we have is build NHibernate from source without the second commit >> capping the alias length and ship it in place of the official distribution. >> If this second commit is actually enforcing correct behaviour, then we'll >> have to figure out why the aliases are getting so long. >> >> Any advice and/or additional insight would be welcomed. >> >> On Wednesday, 12 July 2017 21:25:48 UTC+12, Alex Bunn wrote: >>> >>> Hi all, >>> >>> We've recently started seeing the following exception >>> (NHibernate.MappingException: Unique suffix 10_ length must be less than >>> maximum 3 characters.) being raised on our website about half a dozen times >>> in quick succession before our website goes down, which is frustrating our >>> customers/clients. >>> >>> We've had a look over the NHibernate source code on Github, and found >>> that the max alias length allowed by all of the various dialects is 10, >>> which means according to the error, the first part of the generated alias >>> is 7 characters in length with the remaining 3 being produced (10_) >>> exceeding the remaining character limit. The limit of 10 being reached in >>> our production environment makes no sense, as we're seeing aliases being >>> generated in our local development machines with a length of 10,11 or 12, >>> all of which should be generating an error. >>> >>> We're currently using the most recent version of NHibernate available >>> from NuGet (4.1.1.4000 if my IDE isn't lying to me) and currently >>> developing in C#. >>> >>> We're looking for some additional help/insight on this error so we can >>> figure out what might be causing it, and what we can do to resolve it to >>> make our userbase, and by extension our support/admin team happy. >>> >>> Thanks. >>> >> -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/nhusers. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
