That makes sense to me -- and I agree that sometimes on large apps with many persistent classes (and usually a correspondingly high number of mapping files) building the session factory can be an (embarrasingly) time-consuming process.
Both your and Steve's suggestions for ways to handle some of my related 'infrastructure behavior' concerns seem reasonable -- I just wanted to ensure that we were properly considering the 'real-world' use of this option in the context of the rest of what would need to happen for its implementation to make sense for practical use. If the serialized session factory is auto-built and then serialized on first-run and we use either your or Steve's suggested approach to 'determine the obsolesence of the existing serialized session factory instance', what it seems like we are solving is ONLY the cold-start situation (new app pool in IIS or app-launch in win client), correct? This would seem to have much more applicability to the win client scenario than the web app story except for those very high-traffic, high-availability web apps where the app pool is scheduled for a nightly restart to wipe out the effects of some resource leak that the devs are unable to properly find and fix (which we all know to be a real-world use case!). As a side note, we need to also be cognizant of the fact that its many time the case that there are (of course) multiple session factories per app (ea for a diff DB, ea with a different caching strategy, etc.) and so whatever we come up with as a way to deserialize the factory instance of course needs to reflect this need too (multiple names session factories). -Steve B. On Fri, Feb 6, 2009 at 8:15 AM, 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. > ** > * > >
