Years ago, I consulted on a project where the user was actually changing as
someone was doing work. The app was not allowed into the wild due to this
FUBAR. I found this:

public class ApplicationSettings
{
   private static ApplicationSettings _appSettings;
   private static User _websiteUser;

   private ApplicationSettings() {}

   public ApplicationSettings GetSingleton()
   {
   }

   public ApplicationSettings GetSingleton(string userName)
   {
   }
}

The second GetSingleton was set up to load a User when the person originally
signed in.

The developer thought he was okay, since he was doing this:

Session["appSettings"] = ApplicationSettings.GetSingleton(userName);

Does not matter if you load this into Session or not, as it is a Singleton.
That is one instance per entire application, not per session. He was
constantly flipping from user's object to user's object. Furthermore,
sometimes he was pulling like this:

appSettings = Session["appSettings"];

and sometimes like this:

appSettings = ApplicationSettings.GetSingleton();

I have also seen this:

private static SqlConnection;

public static SqlConnection GetSqlConnection()
{
}

This works fine on a low usage site, but becomes a bottleneck rather quickly
when scaling.

*************************************************
Yep, you're correct.

I'm doing a 'Public Shared blahblah as new DataSet', inside the class.

Partial Class test
   Inherits System.Web.UI.Page
   Public Shared ds As New DataSet

On Mar 12, 9:22 am, "Cowboy \(Gregory A. Beamer\)"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:

And that's the problem... Shared variables (static in C#) are shared across
the entire application in ASP.NET...