ASP.NET Singleton usage

[fredd00]

Hi

I'm just starting with singleton and would like to implement in my new
web app.

I have a question

lets say i create a singleton DataHelper that holds a static
SqlConnection object to share
and on my page I do

SqlConnection cn = DataHelper.GetConnection()


when 2 client request the page making a db call will i get an error
because the connection might be closed or in a state that prevents one
request from using it ?

What would be the advantage of using singleton objects over putting my
objects in application variables?


Thanks

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

lets say i create a singleton DataHelper that holds a static
SqlConnection object to share
and on my page I do

SqlConnection cn = DataHelper.GetConnection()

when 2 client request the page making a db call will i get an error
because the connection might be closed or in a state that prevents one
request from using it ?

You will get some weird errors occasionally.

Singleton is not suited for this type of usage.

To get it working you would need to synchronize access and that
would cripple performance.

Just use connection pool.

What would be the advantage of using singleton objects over putting my
objects in application variables?

Among other thing Singleton can be used in code that are
not web specific.

Arne

 

[Michael Nemtsev]

Hello fredd00,

Just add to Arne, using variables isn;t good idea either. Because asp.net
page has a limited live time

---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

f> What would be the advantage of using singleton objects over putting
f> my objects in application variables?

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

f> What would be the advantage of using singleton objects over putting
f> my objects in application variables?
Just add to Arne, using variables isn;t good idea either. Because
asp.net page has a limited live time

I actually read that as having it in the Application object.

Arne

 

[Guest]

fred00,
If you look at best-practices code like the SqlHelper V2 (Data Access
Application Block) you will see that all the methods are static. The
SqlParameteCache Class therein is also static, so that it can cache
SqlParameter collections across multiple pages and multiple requests.

Singleton provides an instance of a class, but "only one" instance. Take a
look at the code I mentioned and you will see the difference.

Peter

 

[fredd00]

I used to have a helper class that returned a SQLConnection so i guess
i'm already using pooling.

If i want to cache data (let's say dataset) would it be better to
cache it in a singleton or in the Cache object?

I want to use the Data Access Application block , is there data caching
in it ?

thanks

 

[Bob Jones]

I think maybe you're trying too hard to find a reason to use a singleton.

I agree that it's use w/in a web page is kinda pointless because all
the server side things are rebuilt on every trip to the server. And
secondly, saving things to session means you are capturing state. State
means, as I think about it, the specific values of a given object
instance. A singleton is not intended for this kind of use. Unless you
are, on any given trip to the server, creating some number of redundant
objects, I just don't see a need for a singleton.

But here is an example of how we use it. We've created a service - it
runs in the background all the time. This service takes documents and
stores them in our doc archive. The DocImporter is a singleton
instance. Whenever that service is called the singleton ensures that
only one DocImporter object is ever created. This DocImporter object
controls the overall importing process in turn uses the factory pattern
to instantiate any of a number of document type objects, dependent on
the document being imported, of course and one for each document being
imported.

Oh, Additionally, the DocImporter spawns an error logging object when
an error is generated. This ErrorLogger is also a singleton. Errors
generated in the importing process are queued up and wait to be logged
by the one and only ErrorLogger object.

Perhaps the main point here is that the singleton object lives
indefinitely and no client needs it's own specific version of it.

 

[sloan]

See my blog entry:

10/24/2005
Web Session Wrapper for storing and retrieving objects


http://sholliday.spaces.live.com/blog/



In the web environment, I created a singleton which piggyback's off of the
Session object.
It could be an application object as well.

...

Also search for "WeakReference" ............ it allows a holding mechanism
but an "out" if memory demands become too much.