I confess to some confusion about how this proposed change would actually be used in a practical example. Perhaps my ignorance is clouding my vision :)
It seems to me it would have to be either.... 1) call BuildSessionFactory() once at the beginning of your app init (e.g., Main() or Application_Start() in the global.asax) and then persist the serialized already-built session factory to disk so that subsequent calls to get the session factory elsewhere in your code would be able to use the pre-built serialized instance of the session factory 2) create the serialized session factory as some kind of pre-build compilation step so that the serialized instance of the pre-built session factory would be part of the deployment package for the app and the app would then NEVER need to do other than load the session factory from disk and then deserialize it to make use of it If #1 then I must be in the minority of people who have setup my apps to build the session factory just once then provide the same instance of it back to the rest of the app any time its needed to get a new session. In a web app, this 'penalty' is only experienced by the first visitor to the site after the IIS app pool is restarted while in a win client app its perhaps more penalizing since each user each time they launch the app would of course re-experience the 'pain' of building the session factory. But even in this kind of case (where the serialized session factory is built once on first-launch and then serialized to disk for later rapid-loading) wouldn't you nearly always have to rebuild it again on re-launch just to ensure that any config changes (e.g., connection string, etc.) made since it was last serialized are reflected in the 'version' of the session factory that your app is using? If its #2, then this would seem to me to have some merit because in this scenario the pre-built serialized session factory would just be part of the binary deployment package of the app, but in a very real sense it seems to me that this has two big issues: a) how would someone be creating this serialized session factory as part of a build process --? perhaps through some kind of invoked unit test that calls BuildSessionFactory and then persists it to disk? (if so, then we now are saying "you cannot actually build your app unless you also invoke this 'special' unit test here to create the serialized session factory")...? b) NOTHING about the deployment could be changed via a config file (e.g., not even the DB connection string would be part of the config so you would need the 'dev' serialized session factory, the 'test/staging' serialized session factory, the 'prod' serialized session factory, etc. (and that doesn't even touch on the issues of what you do if/when you're building a *product* where each customer needs a different connection string to their own DB --!) In short, while I think I proprerly understand the technical goal here (avoid the performance penalty of calling BuildSessionFactory() by persisting the results of the call to disk for later re-use), I'm not entirely sure I fully understand the practical application of this capability even if we were to build it. I must be overlooking some rather obvious aspect of how this capability would be used in the real world -- can someone take a sec and explain to me what I'm overlooking ??? More confused that usual, -Steve B. On Thu, Feb 5, 2009 at 5:43 PM, Fabio Maulo <[email protected]> wrote: > What is needed is the SessionFactory serialization. The Conf should have a > method to upLoad a serialized sessionFactory and you can use this method > instead call BuildSessionFactory. > > 2009/2/5 Tuna Toksoz <[email protected]> > >> So it comes back to "serializing Configuration" idea? as in ram operations >> are way cheaper than xml validation. >> >> >> Tuna Toksöz >> http://tunatoksoz.com >> http://twitter.com/tehlike >> >> Typos included to enhance the readers attention! >> >> >> >> On Fri, Feb 6, 2009 at 12:31 AM, Fabio Maulo <[email protected]>wrote: >> >>> The BuildSessionFactory is the "in-ram compilation" of all mappings >>> and persistence stuff. >>> Serializing the sessionFactory and saving it to your hard-drive is >>> equivalent to create an "EXE" of the persistence stuff. >>> >> >> > > > -- > Fabio Maulo >
