startup strategie

[Guest]

Hi, I have a question about the startup strategie for my asp.net application.

The application is a website, with behind it a backend webservice used to
retrieve and store data in the choosen database.

When the application starts, one of the first things the app does is loading
the entire dictionary, and the security settings. These are stored an
hastable in the HttpContext.

Question 1: The startup of the application is much to slow. Cause:
retrieving the data from the backend. Is their a good design mechanism to
load the data from the backend, without waiting until it is all loaded?
Problem is that some of the data is needed to generate my webpage (for
example the translations)

Question 2: This data is loaded in the HttpContext. Is this a good place to
store this data, especially when you know that I do pass this HttpContext
between methods?

Thanks in advance!

Michel

 

[MattC]

I would think that the Cache would be a much more suitable place for your
app to store data like that.

MattC

 

[Brock Allen]

Question 1: The startup of the application is much to slow. Cause:

retrieving the data from the backend. Is their a good design mechanism
to load the data from the backend, without waiting until it is all
loaded? Problem is that some of the data is needed to generate my
webpage (for example the translations)

If you need it to do this work prior to starting up, then this is what's
going to happen. If the startup time is too slow, try to defer this processing
(see my comment below).

Question 2: This data is loaded in the HttpContext. Is this a good
place to store this data, especially when you know that I do pass this
HttpContext between methods?

Where in the HttpContext? If you mean the Cache, then that's designed for
cached data. One thing to beware of -- the cache is designed to purge entries
after a timeout (if you specify one) or when you're low on memory (if you
don't disable it) so your programming model always should check if then entry
is in the cache and if it's not it should then go back to the database to
get the data and put it back into the cache.

 

[Guest]

Thanks for the reply.

No I 'm wondering if it might be better to check of the entries are already
loaded, and if not, to load them and store the new ones. Think it will boost
my app a lot.

Also, because the httpcontext is passed a lot between some methods, I'm
looking for another place to store the data.
Currently an instance of a class stores this data in an hashtable. When
loaded, the data is stored in HttpContext.Current.Application["Translator"].
Any suggestions?

Michel

 

[Brock Allen]

I'd stick with the Cache (not Application) as this is what it was designed
for. But keep in mind that no matter where you put the data, there is only
so much memory... so even though the cache was designed for these sorts of
things there are always going to be certain physical limitations.

Thanks for the reply.

No I 'm wondering if it might be better to check of the entries are
already loaded, and if not, to load them and store the new ones. Think
it will boost my app a lot.

Also, because the httpcontext is passed a lot between some methods,
I'm
looking for another place to store the data.
Currently an instance of a class stores this data in an hashtable.
When
loaded, the data is stored in
HttpContext.Current.Application["Translator"].
Any suggestions?
Michel

If you need it to do this work prior to starting up, then this is
what's going to happen. If the startup time is too slow, try to defer
this processing (see my comment below).

Where in the HttpContext? If you mean the Cache, then that's designed
for cached data. One thing to beware of -- the cache is designed to
purge entries after a timeout (if you specify one) or when you're low
on memory (if you don't disable it) so your programming model always
should check if then entry is in the cache and if it's not it should
then go back to the database to get the data and put it back into the
cache.