I guess it wasn't really inline :)
Tuna Toksöz http://tunatoksoz.com http://twitter.com/tehlike Typos included to enhance the readers attention! On Fri, Feb 6, 2009 at 3:15 PM, Tuna Toksoz <[email protected]> wrote: > 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. > ** > * > >
