Static members in ASP .net

[RSH]

If I have a static method that references the HttpContext.Current object is
it safe to be in a static method within a class under ASP .Net?

I know that static classes are shared by all sessions at a given time, so Im
not sure if this can be a static class.

public static SessionManager Instance

{

get

{

HttpContext context = HttpContext.Current;

SessionManager manager = context.Session[SESSION_MANAGER] as SessionManager;

if (manager == null)

{

manager = new SessionManager();

context.Session[SESSION_MANAGER] = manager;

}

return manager;

}

}



Thanks!

Ron

 

[Chris Mullins [MVP - C#]]

This will be valid as long as you call it from methods that are involved in
a postback - this is, areas that actually have a context. If you call this
method from areas that don't have a context - such as a timer callback, or a
thread function, or an async method completion (that doesn't go through the
Async Manager), then this won't work.

Now, with that said, your implementation of the Singleton pattern is broken.
For the reasons behind this, see Jon Skeet's Singleton page at (speficially,
your code is almost identical to his canonical broken example):
http://www.yoda.arachsys.com/csharp/singleton.html

I think you should be very leery of using a Singleton in ASP.Net if you're
not aware of concurrency and the issues that can arise from it (which, based
on your singleton code, you're not really aware of yet...).

ASP.Net is a highly concurrent environment, but developers are often
shielded from that. As soon as you introduce a singleton into the mix,
you're going to run into all mannor of threading & concurrency gotchas, and
will end up with some very unexpected results if you're not carefull.

 

[RSH]

Chris,

Thanks for the very informative post.

I was a little leery about this code, which I found on a "reputable" site,
but it did solve an issue I was dealing with, but while I certainly dont
have your level of expertise I became a little suspicious with the static
method, and the psuedo singleton implementation...especially in an ASP .Net
app.

Thanks...Im sure you saved me a lot of debugging time!
Ron

This will be valid as long as you call it from methods that are involved
in a postback - this is, areas that actually have a context. If you call
this method from areas that don't have a context - such as a timer
callback, or a thread function, or an async method completion (that
doesn't go through the Async Manager), then this won't work.

Now, with that said, your implementation of the Singleton pattern is
broken. For the reasons behind this, see Jon Skeet's Singleton page at
(speficially, your code is almost identical to his canonical broken
example):
http://www.yoda.arachsys.com/csharp/singleton.html

I think you should be very leery of using a Singleton in ASP.Net if you're
not aware of concurrency and the issues that can arise from it (which,
based on your singleton code, you're not really aware of yet...).

ASP.Net is a highly concurrent environment, but developers are often
shielded from that. As soon as you introduce a singleton into the mix,
you're going to run into all mannor of threading & concurrency gotchas,
and will end up with some very unexpected results if you're not carefull.

--
Chris Mullins

If I have a static method that references the HttpContext.Current object
is it safe to be in a static method within a class under ASP .Net?

I know that static classes are shared by all sessions at a given time, so
Im not sure if this can be a static class.

public static SessionManager Instance

{

get

{

HttpContext context = HttpContext.Current;

SessionManager manager = context.Session[SESSION_MANAGER] as
SessionManager;

if (manager == null)

{

manager = new SessionManager();

context.Session[SESSION_MANAGER] = manager;

}

return manager;

}

}



Thanks!

Ron

 

[Guest]

As Chris pointed out field name "Instance" indicates you are attempting to
provide a Singleton (only ever one instance can be created), and if that's
the case the implementation is broken / incomplete.
If it *isn't* intended to be a Singleton, then please use another name for
the field than "Instance".
Peter