yes, you would need to ensure the current transactions are complete before disposing of the session factory.
The "strange" part is not altering the configuration at runtime (although this too is high suspect). It would be strange to attempt to alter the hbm files at run time. the hbm files are design time components. once the system is running you don't change the hbm mappings. similar to how you wouldn't change the templates of your view engine (in windows forms) at runtime. if you are altering the configuration at runtime during the application start there can be value there with minimal pain because the session factory is still only built once. But if you are looking for a system that will alter the domain/database on the fly anytime a user says "create a new property/class" then you are going to have problems that a majority of applications do not experience. Not only is there the issue of altering the domain, there is also the issue of altering the database. do you apply validation, FK/PK constraints, indexing etc. When i have read about runtime configuration changes they are client specific and happen when the application starts. there is still only a single factory built once. the "dynamic" nature of the domain is handled by programmers via code, not a UI that allows users to alter the configuration. put simply: the session factory is not meant to change after it's created. the configuration object is meant to be configured once and then build the session factory. while you *could* alter the configuration and rebuild the session factory during run-time, there are a number of other problems this would introduce. a few are already mentioned in this thread. if the domain requires this level of fluidity (is that a word?) then a compiled language and relational database would hinder that. a dynamic language and a document would make much more sense. On Aug 31, 12:20 am, harshil hameed <[email protected]> wrote: > if we go with rebuild session factory , > like in web applications, wil effect the all current running transaction > naaa, > > how NH can help us to manage this situation(altering the entity mappings at > run time). > > I don't think so Its a strange req.(//many application need dynamic > mapping), > > On Tue, Aug 31, 2010 at 1:15 AM, Jason Meckley <[email protected]>wrote: > > > you have 2 different issues you're dealing with that are independent > > of one another. > > > 1. 2nd level cache. NH uses this to cache entities and queries across > > multiple sessions. the cache is available while the session factory > > exists. the session factory controls 2nd level cache. you are not > > meant to access the cache directly. NH takes care of this for you. > > it's only designed for use by the factory/session for entities. > > nothing else. > > > 2. altering the entity mappings at runtime. hbm's are just 1 option to > > setup the NHibernate.Cfg.Configuration object to build a session > > factory. once the hbms are loaded you can alter the mappings within > > the configuration. if you want to alter the entities at runtime you > > would do so through the configuration object. Make it a singleton and > > keep it around for the life of the application, just like the session > > factory. any time you alter the configuration you will need to dispose > > of the current session factory build a new one from the configuration > > object. session factory is an immutable object, you cannot updated, > > only dispose and build. > > > since 2nd level caching is controlled by the session factory; > > disposing of the session factory will "reset" the 2nd level cache. > > > On Aug 30, 3:16 pm, nadav s <[email protected]> wrote: > > > there's a use case where you have multiple session factories that were > > > configured using different mappings? > > > if so, you'll have to cache it yourself, although it sounds like this > > > scenario isn't possible because you're changing mappings at runtime (you > > > should know that you could change the mappings using the hbm classes of > > the > > > configuration somehow, never done it, but changing the actual xml files > > > sounds really strange). > > > > if you have only one session factory at every given moment, then you can > > use > > > a singleton. > > > > On Mon, Aug 30, 2010 at 8:45 PM, Krishna Jetti <[email protected] > > >wrote: > > > > > Hi Jason, > > > > > Here is my case at an conceptual level. All our entities can be > > > > extended dynamically based on metadata, we are using dynamic-component > > > > for this modelling. At run-time if we change or add metadata for a > > > > domain entity, we will rebuild the session factory, from the > > > > configuration after we have change the .hbm.xml file for those > > > > entities to add or update dynamic-component elements. > > > > > Now, if I enable the 2nd level cache, I can store the metadata > > > > entity so NH will get it from its cache rather than hitting the > > > > database everytime. But I also want to store the session factory as > > > > well so that I don't have to re-configure our .hbm.xml files to build > > > > the session factory. > > > > > Does it make sense ? > > > > > Thanks > > > > > On Aug 30, 12:45 pm, Jason Meckley <[email protected]> wrote: > > > > > Krishna, i think you're confused about how the session factory, > > > > > session and 2nd level cache work together. > > > > > > the session factory is the source of everything in NH. It's created > > > > > from the configuration. the session factory should be a singleton > > > > > within the application and should be created when the application > > > > > starts and disposed when he application ends. > > > > > > sessions are cheap and should be created whenever a new > > "conversation"/ > > > > > unit of work/business context is required. the common scenarios are: > > > > > web > http request > > > > > message bus > thread > > > > > rich client > form > > > > > > 2nd level cache allows you to store entities between sessions to > > > > > bypass the database call. the cache is stored in the session factory > > > > > itself and exists as long as the session factory is around. > > > > > > there is no reason to cache the session factory. if you want to > > > > > decrease the time required to build the session factory you can > > > > > serialize the configuration, but other than that you don't "save" the > > > > > session factory. > > > > > > On Aug 30, 11:53 am, Diego Mijelshon <[email protected]> wrote: > > > > > > > That would be like storing a backpack in a pocket of the same > > backpack. > > > > > > You should use a singleton for your sessionfactory, not a cache. > > > > > > > Diego > > > > > > > On Mon, Aug 30, 2010 at 12:22, Krishna Jetti < > > [email protected] > > > > >wrote: > > > > > > > > Not exactly.....I am looking to actually store in the session > > factory > > > > > > > in the cache. So that when ever there is a request to open the > > > > > > > session, I read the session factory from the cache and open a > > session > > > > > > > for it. > > > > > > > > What I am trying to figure out is...do we have to follow > > conventional > > > > > > > caching techniques or is there anything in the NH that allows to > > > > cache > > > > > > > the session factory? > > > > > > > > Thanks > > > > > > > > On Aug 27, 9:19 am, Gustavo Ringel <[email protected]> > > wrote: > > > > > > > > I think this is what you are looking for: > > > > >http://devlicio.us/blogs/tuna_toksoz/archive/2009/03/14/an-improvemen. > > .. > > > > > > > > > On Fri, Aug 27, 2010 at 4:14 PM, Krishna Jetti < > > > > [email protected] > > > > > > > >wrote: > > > > > > > > > > Hello All, > > > > > > > > > > Is it possible to cache the session factory using any of > > the > > > > > > > > > available cache providers for NH2.1.2. I understand that any > > > > entities > > > > > > > > > related to session factory can be cached but is there a way > > to > > > > > > > > > configure NH to cache the session factory it self > > > > > > > > > > Thanks > > > > > > > > > > -- > > > > > > > > > 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]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%252bunsubscr...@googlegroups.com> > > > > > > > > > > > > > > > > > . > > > > > > > > > For more options, visit this group at > > > > > > > > >http://groups.google.com/group/nhusers?hl=en.-Hidequotedtext- > > > > > > > > > - Show quoted text - > > > > > > > > -- > > > > > > > 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]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%[email protected]> > > > > > > > > > > > > > . > > > > > > > For more options, visit this group at > > > > > > >http://groups.google.com/group/nhusers?hl=en.-Hidequoted text - > > > > > > - Show quoted text - > > > > > -- > > > > 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]> > > <nhusers%[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]<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.
