Static fields in ASP.NET pages

[mark.norgate]

Hello

I'm writing an application in ASP.NET 1.1 and have come across a
problem using static fields in my page classes.

I have lots of controls on the page that all need to bind to the same
datasource, so I thought I'd create a singleton in the base class that
reads from the database and provides a DatasSet to all instances of the
various derived classes. I've discovered, though, that the static
values persist between roundtrips, presumably because the singleton
instance hasn't been released by the garbage collector. For this
reason, I've decided that using static in my ASP.NET pages is probably
unsuitable.

Does anyone have any recommendations for using static members in
ASP.NET, or is there a more appropriate method for implementing
singletons in ASP.NET?

Thanks a lot, Mark

 

[Eliyahu Goldin]

Mark,

Note, that static members persist not only between roundtrips of the same
session, but also between different sessions of the same application. This
means that multiple users working in the same time will be working on the
same objects.

Eliyahu

 

[Hans Kesting]

Hello

I'm writing an application in ASP.NET 1.1 and have come across a
problem using static fields in my page classes.

I have lots of controls on the page that all need to bind to the same
datasource, so I thought I'd create a singleton in the base class that
reads from the database and provides a DatasSet to all instances of the
various derived classes. I've discovered, though, that the static
values persist between roundtrips, presumably because the singleton
instance hasn't been released by the garbage collector. For this
reason, I've decided that using static in my ASP.NET pages is probably
unsuitable.

Does anyone have any recommendations for using static members in
ASP.NET, or is there a more appropriate method for implementing
singletons in ASP.NET?

Thanks a lot, Mark

A singleton should not be "released by the garbage collector". It
should remain alive for the duretion of the application.
An asp.net application is a single application that keeps on running
until you explicitly stop it. During this lifetime it serves many
sessions consisting of many requests.

It is possible to use static members and singletons in asp.net, but you
need to know the effects: *all* users will the use the *same*
instances. If that is what you want, fine.

What you may want is static *methods*. You don't need to instantiate
the class, you can (or rather: need to) call these on the *type*.
Example:

public sealed class MyLibrary
{
private MyLibrary() { } // no public constructor needed

public static DataSet GetData(int id)
{
// ....
return ..;
}
}

and you call that with:

DataSet ds = MyLibrary.GetData(1);



Hans Kesting

 

[mark.norgate]

Thanks Hans. Perhaps I ought to be a little more explicit with my
requirements.

My intention is that the singleton instance should be alive for the
duration of the request, on a per-user basis. When the page goes out of
scope, the singleton should be destroyed; or, more precisely, the data
should be reloaded when the page is loaded afresh by the server in
response to a fresh request (i.e., not a postback).

There are two problems: the singleton instance is shared across
threads, but I suspect I may be able to deal with that using the
ThreadStaticAttribute attribute; more importantly is the fact that the
singleton is surviving roundtrips to the server. If I implement
ThreadStaticAttribute then perhaps this won't be the case. This leads
to another question: is a thread created when a request is made of the
server, and does it end when the request has been fulfilled, or does it
end when the session goes out of scope?

As for your static method suggestion, what effect does marking it as
static have? Presumably the function will be executed every time it is
called, so that will defeat the whole reason I wanted a singleton in
the first place: to make sure the data is only loaded once from the
database per visit to the page (including postbacks).

Aargh!

Mark