«

Hi all, I wanted to know if there are any limitations to storing some custom
objects I have written at application level to avoid having to
create/destroy with every request. These are not ado objects, just some
custom ones I have written with basically functions and method that do some
basic stuff - file i/o etc. I know there used to be limitations with classic
asp and application objects. Do the same apply to asp.net?

TIA,
RP

The limitations have been mostly removed. If you wrap file I/O stuff or
connection objects remember to dispose of them correctly so that you don't
leak memory.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"RP" <> wrote in message
news:#...
> Hi all, I wanted to know if there are any limitations to storing some
custom
> objects I have written at application level to avoid having to
> create/destroy with every request. These are not ado objects, just some
> custom ones I have written with basically functions and method that do
some
> basic stuff - file i/o etc. I know there used to be limitations with
classic
> asp and application objects. Do the same apply to asp.net?
>
> TIA,
> RP
>
>

Thanks for the reply. So when is it recommended and when is it not
recommended to store commonly used objects at application state?

thanks!

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:...
> The limitations have been mostly removed. If you wrap file I/O stuff or
> connection objects remember to dispose of them correctly so that you don't
> leak memory.
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
> "RP" <> wrote in message
> news:#...
> > Hi all, I wanted to know if there are any limitations to storing some
> custom
> > objects I have written at application level to avoid having to
> > create/destroy with every request. These are not ado objects, just some
> > custom ones I have written with basically functions and method that do
> some
> > basic stuff - file i/o etc. I know there used to be limitations with
> classic
> > asp and application objects. Do the same apply to asp.net?
> >
> > TIA,
> > RP
> >
> >
>
>

Application objects have scope as long as the application is running. When a
first user logs in to the system, the application starts to run. It doesn't
terminate when the user logs off or closes the browser. It may stop for
example when IIS resets or when you explicitly terminate the application so
conceivably the application can be running for days. Do you want your
objects to persist that long? Its up to you. Objects in the application
object can be accessed by all aspx pages. These objects are not thread safe
so you will need to take the appropriate synchronization precautions just
like you do with global objects because that is what they are. There are
quite a number of articles on msdn to guide you thru.

regards.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"RP" <> wrote in message
news:...
> Thanks for the reply. So when is it recommended and when is it not
> recommended to store commonly used objects at application state?
>
> thanks!
>
> "Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
> message news:...
> > The limitations have been mostly removed. If you wrap file I/O stuff or
> > connection objects remember to dispose of them correctly so that you
don't
> > leak memory.
> >
> > --
> >
> >
> > -----------
> > Got TidBits?
> > Get it here: www.networkip.net/tidbits
> > "RP" <> wrote in message
> > news:#...
> > > Hi all, I wanted to know if there are any limitations to storing some
> > custom
> > > objects I have written at application level to avoid having to
> > > create/destroy with every request. These are not ado objects, just
some
> > > custom ones I have written with basically functions and method that do
> > some
> > > basic stuff - file i/o etc. I know there used to be limitations with
> > classic
> > > asp and application objects. Do the same apply to asp.net?
> > >
> > > TIA,
> > > RP
> > >
> > >
> >
> >
>
>

The most important thing to remember is that, while you can still store
items in the Application Collection, it is not threadsafe, and it is
therefore recommended that you use the Application Cache, which was designed
specifically for ASP.Net instead.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.

"RP" <> wrote in message
news:...
> Thanks for the reply. So when is it recommended and when is it not
> recommended to store commonly used objects at application state?
>
> thanks!
>
> "Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
> message news:...
> > The limitations have been mostly removed. If you wrap file I/O stuff or
> > connection objects remember to dispose of them correctly so that you
don't
> > leak memory.
> >
> > --
> >
> >
> > -----------
> > Got TidBits?
> > Get it here: www.networkip.net/tidbits
> > "RP" <> wrote in message
> > news:#...
> > > Hi all, I wanted to know if there are any limitations to storing some
> > custom
> > > objects I have written at application level to avoid having to
> > > create/destroy with every request. These are not ado objects, just
some
> > > custom ones I have written with basically functions and method that do
> > some
> > > basic stuff - file i/o etc. I know there used to be limitations with
> > classic
> > > asp and application objects. Do the same apply to asp.net?
> > >
> > > TIA,
> > > RP
> > >
> > >
> >
> >
>
>

Good point. Thanks for the info.

"Kevin Spencer" <> wrote in message
news:...
> The most important thing to remember is that, while you can still store
> items in the Application Collection, it is not threadsafe, and it is
> therefore recommended that you use the Application Cache, which was
designed
> specifically for ASP.Net instead.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> http://www.takempis.com
> Big Things are made up of
> Lots of Little Things.
>
> "RP" <> wrote in message
> news:...
> > Thanks for the reply. So when is it recommended and when is it not
> > recommended to store commonly used objects at application state?
> >
> > thanks!
> >
> > "Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote
in
> > message news:...
> > > The limitations have been mostly removed. If you wrap file I/O stuff
or
> > > connection objects remember to dispose of them correctly so that you
> don't
> > > leak memory.
> > >
> > > --
> > >
> > >
> > > -----------
> > > Got TidBits?
> > > Get it here: www.networkip.net/tidbits
> > > "RP" <> wrote in message
> > > news:#...
> > > > Hi all, I wanted to know if there are any limitations to storing
some
> > > custom
> > > > objects I have written at application level to avoid having to
> > > > create/destroy with every request. These are not ado objects, just
> some
> > > > custom ones I have written with basically functions and method that
do
> > > some
> > > > basic stuff - file i/o etc. I know there used to be limitations with
> > > classic
> > > > asp and application objects. Do the same apply to asp.net?
> > > >
> > > > TIA,
> > > > RP
> > > >
> > > >
> > >
> > >
> >
> >
>
>