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%252bunsubscr...@googlegroups.com> > > > > > > > > > > > . > > > > > > 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.- Hide quoted 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]> > . > 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.
