Thinking aloud, I'm guessing that you'd want it to be fully automatic.
i.e., option 1 from your choices. Ideally, BuildSessionFactory would do
this itself internally, so that the user doesn't have to know. You
could, perhaps, disable this behaviour through configuration if you
really wanted (perhaps you app doesn't have permission to write to disk,
for example).
To handle config changes, I'd suggest the a hash of the config is stored
along with the serialised factory; that way, changes can be detected
automatically and the persisted version can be trashed.
Cheers,
Steve
Stephen Bohlen wrote:
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]
<mailto:[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] <mailto:[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://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] <mailto:[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
