By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,910 Members | 1,077 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,910 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.
Nov 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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.

Nov 18 '05 #2

P: n/a
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.


Nov 18 '05 #3

P: n/a
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.


Nov 18 '05 #4

P: n/a
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.


Nov 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.