Singleton pattern with webservices

[koredump]

I have inherited a Business Object architecture that makes heavy use
of the Singleton design patter. For example the data access layer
class is implemented as a static Singleton "object", there are also
other business objects logic and security supporting classes that are
all implemented using the Singleton patter. I 'm attempting to make
use of this class library in a webservice application. The problem is
that some of the Singleton objects use static variables to store data
and that will cause problems in the webservice environment where all
static variables are equivalent to application level variables. I've
done some research and found an alternate way of instantiating these
Singleton objects.
I would like to get your opinion as to how reliable this method will
be (when used in the webservice and a single threaded windows app) and
any potential pitfalls. Looks like this type of Singleton
instantiation will guerantee that each web app thread will have its
own static variables.

TIA for your time.

(Found at http://ehsanbraindump.blogspot.com/2007/05/singleton-ammendment-1.html)

public class ConnectionManager
{
/* ConnectionManager implementation */

//Singleton logic:
private ConnectionManager() { }

public static ConnectionManager Instance
{
get
{
if (Thread.GetData(Thread.GetNamedDataSlot("ConnectionManager")) ==
null)
Thread.SetData(Thread.GetNamedDataSlot("ConnectionManager"), new
ConnectionManager());

return
(ConnectionManager)System.Threading.Thread.GetData(Thread.GetNamedDataSlot("ConnectionManager"));
}
}
}

Rich

 

[Jon Skeet [C# MVP]]

I have inherited a Business Object architecture that makes heavy use
of the Singleton design patter. For example the data access layer
class is implemented as a static Singleton "object", there are also
other business objects logic and security supporting classes that are
all implemented using the Singleton patter. I 'm attempting to make
use of this class library in a webservice application. The problem is
that some of the Singleton objects use static variables to store data
and that will cause problems in the webservice environment where all
static variables are equivalent to application level variables. I've
done some research and found an alternate way of instantiating these
Singleton objects.
I would like to get your opinion as to how reliable this method will
be (when used in the webservice and a single threaded windows app) and
any potential pitfalls. Looks like this type of Singleton
instantiation will guerantee that each web app thread will have its
own static variables.

Well, firstly I'd say it no longer counts as a singleton - a factory,
more like.

It would be simpler just to use the ThreadStatic attribute, to be
honest, but I dare say it'll work.

However, you *do* need to be careful of ASP.NET thread agility. In some
situations (and it's version-dependent) a request can hop around
multiple different threads during its lifetime. If it's important that
you use a single ConnectionManager for all the different parts of the
life cycle, you'll need to rethink this.

 

[koredump]

Thanks for that Jon. But...

In situations (and it's version-dependent) a request can hop around
multiple different threads during its lifetime.

My understanding of how the aspnet worker process works is as follows:
There is a pool of threads that serves all the web requests.
Once a thread is assigned to process a web request it's removed fromt the
threadpool, it then processes the web request from start to finish. After it
is done with the web request, the thread is return to the thread pool.
Are you saying that one thread could be serving multiple requests at the
same exact time?

 

[Jon Skeet [C# MVP]]

Thanks for that Jon. But...


My understanding of how the aspnet worker process works is as follows:
There is a pool of threads that serves all the web requests.
Once a thread is assigned to process a web request it's removed fromt the
threadpool, it then processes the web request from start to finish. After it
is done with the web request, the thread is return to the thread pool.
Are you saying that one thread could be serving multiple requests at the
same exact time?

I'm saying that parts of the same web request's lifecycle can occur on
different threads in some situations, at least with ASP.NET 1.1.

I was investigating this recently and posted my results on a discussion
topic: see http://forum.springframework.net/showthread.php?t=572