Singleton in a Web app

**Steve Walker** · Nov 17 '05, 03:00 AM

Re: Singleton in a Web app

In message <627d2$4283163a $42a1e6c9$14131 @FUSE.NET>, Sgt. Sausage
<nobody@nowhere .com> writes
[color=blue]
>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.[/color]
[color=blue]
>(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?[/color]

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.

--
Steve Walker

**Ignacio Machin \( .NET/ C# MVP \)** · Nov 17 '05, 03:01 AM

Re: Singleton in a Web app

Hi,

[color=blue]
> 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.[/color]

Yes, this is correct it will be "singleton" in the application context
meaning that all the sessions will share the same instance
[color=blue]
> (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.[/color]

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.
[color=blue]
> (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.[/color]

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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

**Samuel R. Neff** · Nov 17 '05, 03:01 AM

Re: Singleton in a Web app

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

On Thu, 12 May 2005 04:39:00 -0400, "Sgt. Sausage"
<nobody@nowhere .com> wrote:
[color=blue]
>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
>
>[/color]

**Sgt. Sausage** · Nov 17 '05, 03:04 AM

Re: Singleton in a Web app

"Samuel R. Neff" <inforeliance@n ewsgroup.nospam > wrote in message
news:u5m681d7eb goppiv2vqe66igi 956gp39fu@4ax.c om...
[color=blue]
> 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.[/color]

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

Thanks!

[snippage]

Singleton in a Web app

Singleton in a Web app

Comment

Comment

Comment

Comment