scope of singleton static refs in ASP.NET 2.0

[John A Grandy]

For a singleton class utilizes by ASP.NET 2.0 page processing:

When initial instantiation is performed during the initial call to the
retrieve instance method (let's call the method "getInstance()"), an
instantiated object of the class is assigned to the class' internal static
reference to that an object of itself (let's call the reference
"uniqueInstance")

Does that uniqueInstance have global scope in the context of page processing
?

In other words, will subsequent calls to getInstance() find uniqueInstance
!= null , and return it ? Or will they find uniqueInstance == null , and
re-instantiate an object of the class and assign it to unique instance ?

 

[Greg Young]

Within the same appdomain the static variable will be set.

ASP.NET apps often however cross multiple worker process (as such multiple
app domains). If the next request came to a different worker process it
would use a different singleton instance.

Cheers,

Greg

 

[John A Grandy]

Hi Greg, and thanks for the response.

By "next request came to a different worker process" are you referring to

(a) a call by another w3wp to the same method of the same singleton
data-access class that had previously been called by another w3wp in the
course of processing a specific page request

--or--

(b) during a subsequent page request by the same (or another) client, a call
is made to the same method of the same singleton data-access class

Thanks again.

 

[Greg Young]

A) ... in another process ... subsequent calls to the same appdomain will
reuse the same singleton. Also keep in mind that from time to time
applications recycle their worker processes which would also force the
singleton to be re-created (new process = new app domain)

 

[tljones]

John, are you storing your instance in HttpContext.Current? Or for
each page are you just doing:

Singleton sg = Singleton.Instance();

Where the Instance method just returns the instance created when the
Singleton class was initialized?

Thanks.

TJ

 

[John A Grandy]

I haven't coded anything yet. I'm trying to determine if there is any
advantage to using singletons to improve performance of ASP.NET 2.0
web-apps.

From what I have learned so far, in almost any scenario there is no
advantage, because object instantiation is so cheap in .NET

In fact, there may even be a disadvantage to sharing singleton instances
across multiple page requests, due to multi-threading issues and locking.
This is the area I'm not sure about.

Right now, the area I'm concentrating is processing of a single page request
:

* Over the course of processing a single page request from a single client,
I believe that the advantages/disadvantages of storing class instance(s) in
some sort of cache (and removing them from the cache at end of page
processing) are only relevant if the class object requires a lot of
initialization.

That I know of , there are 4 types of cache the Page can easily use during
in-Page processing: HttpContext.Current.Application ,
HttpContext.Current.Session , or HttpContext.Current.Cache (Page.ViewState
could also be used ... but this would be a mis-use).

Assuming little or not initialization of the class object is required, it
seems that the overhead of retrieving the object from the cache is
approximately the same as the overhead of creating the object fresh.

* What confuses me about singletons in an ASP.NET web-app is the following:
Is it required to cache the singleton object ? True, the singleton has a
internal static reference to a single instance of itself , but, once
instantiated, does this assigned static reference protect the instance from
being disposed and GC'd once all other references to it have been dropped ?

For example: In a class method Class1.Method1() called during Page
processing , I perform dao = singletonDAO.getInstance() , make calls to
dao.method1() , dao.method2(), etc. ... once Class1.Method1() is completed,
is singletonDAO's internal static reference to an instance of itself
disposed (i.e. marked as ready for GC) ?

 

[Alvin Bruney]

What confuses me about singletons in an ASP.NET web-app is the following:
Is it required to cache the singleton object ?

You shouldn't need to cache the singleton if there is a static reference.

Assuming little or not initialization of the class object is required, it
seems that the overhead of retrieving the object from the cache is
approximately the same as the overhead of creating the object fresh.

Cache retrieval is extremly fast and scalable as well. If your object
overhead is non-trivial, the cache approach is better.

is singletonDAO's internal static reference to an instance of itself
disposed (i.e. marked as ready for GC) ?

No, static variables persist until the app domain unloads.
--

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

 

[Richard Blewett [DevelopMentor]]

A) ... in another process ... subsequent calls to the same appdomain will
reuse the same singleton. Also keep in mind that from time to time
applications recycle their worker processes which would also force the
singleton to be re-created (new process = new app domain)

Also ASP.NET can recycle the web app's AppDomain without recycling the whole
process which will have the same effect on the singleton

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk