Hello Diego, Thank you for the reply. Apparently I did a poor job of searching the group and I apologize if I wasted peoples time. I did end up finding a few posts from Fabio where he recommended inheriting from DriverConnectionProvider and overriding the ConnectionString property so I'll give that a shot.
Aside from the Second Level Cache, are there any other gotcha's/issues with using the same Session Factory? I agree, we need some serious server upgrades and should be on 2.1. Thank you, Mike On Jan 24, 9:21 am, Diego Mijelshon <[email protected]> wrote: > If you have 120 databases, it seems to me like you should have a big server > there... in which case 700MB is nothing. This is 2010, 1GB costs 20 bucks. > > Still... you might want to try with a single session factory and passing the > IDbConnection to the OpenSessionMethod. > And... you should really, really switch to the lastest NH version (2.1.2) > > Diego > > On Sat, Jan 23, 2010 at 22:58, Mike Smith <[email protected]>wrote: > > > Hello, > > > I am hoping you nHibernate gurus can help us with our problem! > > > We are using nHibernate version 1.2.1.4000, have many databases with > > identical schemas, and per the standard recommendation we create a > > singleton Session Factory for each database. We have an ASP.Net > > application for the UI, and a Windows Service that performs background > > operations. > > > With over a 100 class table mappings (plus relationships and queries), > > and having over 120 databases, we are seeing our applications use an > > extraordinary amount of memory (~700MB when all 120+ Session Factories > > have been created). Using CLR Profiler, it appears nearly all of the > > memory on the heap is chewed up from the string data generated from > > nHibernate SessionFactoryImpl (hashtables, sqlstrings, loaders, etc.) > > which means it will never get cleaned up until the application is shut > > down. I did verify that we have the correct number of session > > factories (1 per db) so that code is working fine. > > > For our situation, it would be ideal and more efficient to only have > > to load the mappings one time, and be able to use them across all of > > our databases. > > > The big question: Assuming we are not using the Second Level Cache, is > > it possible/safe to use the same Session Factory for all of our > > databases? Do other people do this? If so, I assume we would have to > > handle the connection management...any thoughts on that? > > > If not, how do people handle this? Our number of databases and > > mappings are going to continue to grow and we need to act now. Can you > > think of any ways to make this more efficient? I suppose we could > > start disposing of Session Factory's if they aren't used for a while, > > but it would be a shame to have the delay, and in peak usage time it > > may not help at all. Are there any config settings that would help > > balance out memory usage vs delay of loading? Maybe new features in > > the latest nHibernate release which would help us out? > > > Our configuration settings: > > <nhibernate> > > <add key="hibernate.connection.provider" > > value="NHibernate.Connection.DriverConnectionProvider"/> > > <add key="hibernate.dialect" > > value="NHibernate.Dialect.MsSql2005Dialect" /> > > <add key="hibernate.connection.driver_class" > > value="NHibernate.Driver.SqlClientDriver"/> > > <add key="hibernate.show_sql" value="false" /> > > <add key="hibernate.max_fetch_depth" value="3" /> > > </nhibernate> > > > Our code for creating a new SessionFactory (if it doesn't already > > exist): > > Configuration config = new Configuration(); > > config.AddAssembly("Assembly.Name"); > > config.SetProperty("hibernate.connection.connection_string", > > connectionString); > > sessionFactory = config.BuildSessionFactory(); > > sessionFactoryDictionary.Add(connection_name, sessionFactory); > > > Thanks so much! > > Mike > > > -- > > 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. > > -- 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.
