Indeed. Tuna Toksöz http://tunatoksoz.com http://twitter.com/tehlike
Typos included to enhance the readers attention! On Fri, Feb 6, 2009 at 3:30 PM, Ayende Rahien <[email protected]> wrote: > Just one note, > for big web app, the benefit isn't for the users, it is for the developers. > Imagine that we can reduce startup time from NH from 15 seconds to 2 > seconds. Now we save the developers 13 seconds each time they hit F5. > > > > On Fri, Feb 6, 2009 at 3:26 PM, Stephen Bohlen <[email protected]> wrote: > >> 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. >>> ** >>> * >>> >>> >> >
