Singleton in a Web app

  • Thread starter Thread starter Sgt. Sausage
  • Start date Start date
S

Sgt. Sausage

This may not be the best place to post this, but I'm
coding in c# and, well this group is a "csharp" group!

Background -- We encapsulate data access for an application
through a home-grown "DataEngine" object. This object follows
the singleton pattern. All is well and good, and everything
works just great for our desktop apps that hit the database
through the DataEngine.

Now, we've got to expose the DataEngine object to a web
server. Initially, I'm concerned. I don't do much (any)
web programming, but I've got a good feel for how it works.

My concern is that the DataEngine, being a singleton, will
be shared amongst all user sessions on the web server for
this site. This brings up 2 related major issues that I
have no clue on.

(1) Multi-threading. The DataEngine is not "thread-safe".
It assumes a single user. This was a good, valid assumption
based on the way we build our desktop apps.

(2) If I start locking things up to make it "thread-safe",
I believe I'm in a world of hurt as far as the DataEngine
becoming a bottleneck on the web server.

Do these concerns make sense? What do other folks do in
similar situations?

Thanks.

-- Sarge
 
Sgt. Sausage said:
My concern is that the DataEngine, being a singleton, will
be shared amongst all user sessions on the web server for
this site. This brings up 2 related major issues that I
have no clue on.

(1) Multi-threading. The DataEngine is not "thread-safe".
It assumes a single user. This was a good, valid assumption
based on the way we build our desktop apps.
Click to expand...
(2) If I start locking things up to make it "thread-safe",
I believe I'm in a world of hurt as far as the DataEngine
becoming a bottleneck on the web server.

Do these concerns make sense? What do other folks do in
similar situations?
Click to expand...

So it is currently a singleton within the context of a single user's
application? Is it definitely not thread-safe, or just not explicitly
designed to be so? Does it hold any state which would be unique to a
single user, or make any assumptions about the order of consecutive
calls?

I can see no reason why it being a singleton would in itself cause
problems, however the reasons for making it a singleton in the first
place may mean that it's unsuitable. As a thought experiment, and
ignoring any database connection logic, would it still work if you made
all of the methods static? I'm not suggesting this as a solution, just
fishing for the design of the thing.
 
Hi,

My concern is that the DataEngine, being a singleton, will
be shared amongst all user sessions on the web server for
this site. This brings up 2 related major issues that I
have no clue on.
Click to expand...

Yes, this is correct it will be "singleton" in the application context
meaning that all the sessions will share the same instance
(1) Multi-threading. The DataEngine is not "thread-safe".
It assumes a single user. This was a good, valid assumption
based on the way we build our desktop apps.
Click to expand...

Well, I have a similar deployment in a couple of application and I have
never had a single issue, it all depends of how you coded the DataEngine
though. In mine I export methods similars to the SqlCommand (
ExecuteNonQuery, ExecuteScalar, etc) I made sure that I use no instance
variables in this case, I create a connection in each method ( and close it
at the end of the method) so the class is thread safe.
(2) If I start locking things up to make it "thread-safe",
I believe I'm in a world of hurt as far as the DataEngine
becoming a bottleneck on the web server.
Click to expand...

It will, don;t do it, first make sure if you need to lock something, most
probably you could recode it in such a way that no instance variables are
used ( or values are modified ) and hence you do not need a sync mechanism.


Cheers,
 
Move the state data in the singleton object to separate state objects.
Instantiate the state objects on the initial call into the singleton
and pass them arround. Therefore all your methods become
stateless--they rely on the parameter for state maintenance.

I also just recently switched to web development from desktop and the
biggest difference is the necessity of making all back-end classes
(data/business logic stuff) stateless. To account for this pass
around state parameters as needed but also evaluate if they really are
needed--if the object can do it's work without all the state, then
just pass it what it needs.

There are also context stores you can use for state management that is
specific to a single call--HttpContext in web pages and services,
CallContext in remoting. These can be used for storing state for a
single call throughout the call, but should be used sparingly--more
for design issues related to isolation of layers, technologies, and
change risk as opposed to performance.

HTH,

Sam
 
Move the state data in the singleton object to separate state objects.
Instantiate the state objects on the initial call into the singleton
and pass them arround. Therefore all your methods become
stateless--they rely on the parameter for state maintenance.
Click to expand...

Bravo! That's just the piece I was missing. One of those
"well ... duh!" moments for me. That should do the trick.

Thanks!

[snippage]
 
Back
Top