Inline * 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?
**You're right, it is the advised way of using session factory. However, as you said this penalty can sometimes bit seconds if not minutes for SessionFactory to initialize, reducing this is a good option. We can leave it upto the developer to make this change and remove the stuff if there is a change. Another option would be to have timestamps stored elsewhere to make sure the Domain and .Config file didn't change, and this wouldn't take so long, I guess.* * My proposal would be to have a STATIC SessionFactory per application, which is initialized like the following 1. Check if there is a SessionFactory Serialization Binary 2. If yes, then check .config file and related assembly Last Modified Date, if those are newer than the Serialized factory, then go to step 4. If not step 3 **3. **Now we have a valid session factory, we can safely deserialize it. 4. Means that we either don't have a session factory, or it is pretty old. Create the session factory once more, serialize it to the disk. ** *
