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

Singleton pattern with webservices

P: n/a
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/2...endment-1.html)

public class ConnectionManager
{
/* ConnectionManager implementation */

//Singleton logic:
private ConnectionManager() { }

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

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

Rich

Jul 18 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
koredump <ko******@interia.plwrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jul 18 '07 #2

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


Jul 19 '07 #3

P: n/a
koredump <te**@test.comwrote:
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?
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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jul 19 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.