What's the current wisdom on storing objects in the Application Variable?

[Frank Rizzo]

In classic ASP, it was considered a bad idea to store VB6-created
objects in the Application variable for various threading issues.

What's the current wisdom on storing objects in the Application variable
in ASP.NET?

I am thinking of storing several objects there, not too large, so there
won't be any memory issues or anything like that. Is ASP.NET still
subject to threading issues?

Thanks.

[Hermit Dave]

any shared objects do need to worry bout threading... so make it thread
safe...
use lock / mutexs etc to make it thread safe..

and application isnt the best place to store any data.. instead try using
cache object
cache object is smart... you can set the priority and you can set absolute /
sliding expiry times.. you can set callbacks if the object is unloaded...
and most important... cache removes object if its overloaded... and the way
it removes it is based on priority set by you..

application on the other hand would cause a restart if overloaded with data.

--
Regards,

HD

"Frank Rizzo" <no**@none.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

In classic ASP, it was considered a bad idea to store VB6-created
objects in the Application variable for various threading issues.

What's the current wisdom on storing objects in the Application variable
in ASP.NET?

I am thinking of storing several objects there, not too large, so there
won't be any memory issues or anything like that. Is ASP.NET still
subject to threading issues?

Thanks.

[Hermit Dave]

couple of links to help you

creating multi threaded object in c#
http://msdn.microsoft.com/library/de...ithvisualc.asp

cache object
http://msdn.microsoft.com/library/de...classtopic.asp

--
Regards,

HD

"Hermit Dave" <he************@CAPS.AND.DOTS.hotmail.com> wrote in message
news:ee**************@TK2MSFTNGP10.phx.gbl...

any shared objects do need to worry bout threading... so make it thread
safe...
use lock / mutexs etc to make it thread safe..

and application isnt the best place to store any data.. instead try using
cache object
cache object is smart... you can set the priority and you can set absolute / sliding expiry times.. you can set callbacks if the object is unloaded...
and most important... cache removes object if its overloaded... and the way it removes it is based on priority set by you..

application on the other hand would cause a restart if overloaded with data.
--
Regards,

HD

"Frank Rizzo" <no**@none.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

In classic ASP, it was considered a bad idea to store VB6-created
objects in the Application variable for various threading issues.

What's the current wisdom on storing objects in the Application variable
in ASP.NET?

I am thinking of storing several objects there, not too large, so there
won't be any memory issues or anything like that. Is ASP.NET still
subject to threading issues?

Thanks.

[Scott Allen]

Hi Frank:

You can keep a .NET object in Application state, but you do need to be
careful to avoid concurrent access and bottlenecks.

If the objects are not frequently used - consider the Cache object
instead. 'Frequently' is a relative term of couse...

It would still be a bad idea to store VB6 objects in Application state
in ASP.NET, as they need to run in a single threaded apartment - but I
don't think that was what you were asking.

--
Scott
http://www.OdeToCode.com

On Tue, 13 Jan 2004 12:15:37 -0800, Frank Rizzo <no**@none.com> wrote:

In classic ASP, it was considered a bad idea to store VB6-created
objects in the Application variable for various threading issues.

What's the current wisdom on storing objects in the Application variable
in ASP.NET?

I am thinking of storing several objects there, not too large, so there
won't be any memory issues or anything like that. Is ASP.NET still
subject to threading issues?

Thanks.

[Frank Rizzo]

Scott Allen wrote:

Hi Frank:

You can keep a .NET object in Application state, but you do need to be
careful to avoid concurrent access and bottlenecks.
I want to store read-only objects that would be loaded in the beginning
of the app via global.asax. This would have things like lookup lists,
connection string, etc...things that would not change for the duration
of the application. Given that the data is read-only, would I still
have to worry about concurrent access?

Given this information, do I still need to use the Cache object?


If the objects are not frequently used - consider the Cache object
instead. 'Frequently' is a relative term of couse...

It would still be a bad idea to store VB6 objects in Application state
in ASP.NET, as they need to run in a single threaded apartment - but I
don't think that was what you were asking.

--
Scott
http://www.OdeToCode.com

On Tue, 13 Jan 2004 12:15:37 -0800, Frank Rizzo <no**@none.com> wrote:

In classic ASP, it was considered a bad idea to store VB6-created
objects in the Application variable for various threading issues.

What's the current wisdom on storing objects in the Application variable
in ASP.NET?

I am thinking of storing several objects there, not too large, so there
won't be any memory issues or anything like that. Is ASP.NET still
subject to threading issues?

Thanks.