Static Singleton In ASP.Net Session

Question

I've been reading about singletons in ASP.Net and I've seen various implementations and suggestions. I've tried to model my implementation after this one: https://stackoverflow.com/...asp-net-singleton

Here is my question: I would like the object that I'm instantiating to last the life of the current session, but not be shared between sessions. For example, if two users are logged in at the same time, I want them to each "own" an instance of a global object. Below is my implementation. Is this the proper way to do this?

public class AppGlobal
{
    #region Contructors

    public AppGlobal() { }

    public static AppGlobal Instance
    {
        get
        {
            HttpSessionState session = HttpContext.Current.Session;

            if (session["AppGlobalInstance"] == null)
            {
                session["AppGlobalInstance"] = new AppGlobal();
            }

            return (AppGlobal)session["AppGlobalInstance"];
        }
    }

    #endregion

    #region Public Properties

    public User UserObject { get; set; }
    public Campaign CampaignObject { get; set; }
    public List<int> SelectedContactIDs = new List<int>();
    public List<int> UnsubmittedContactIDs = new List<int>();
    public List<int> SubmittedContactIDs = new List<int>();
    public List<int> ProcessedContactIDs = new List<int>();

    #endregion

    #region Public Instance Methods

    public void ClearCampaign()
    {
        CampaignObject = null;
        UnsubmittedContactIDs.Clear();
        SubmittedContactIDs.Clear();
        ProcessedContactIDs.Clear();
        SelectedContactIDs.Clear();
    }
    public void LoadCampaign(int campaignID)
    {
        //Ensure that old data is overwritten
        MailCampaignManagerEntities db = new MailCampaignManagerEntities();

        db.Campaigns.MergeOption = System.Data.Objects.MergeOption.OverwriteChanges;

        //Clear the campaign and associated data
        ClearCampaign();

        //Set campaign object in AppGlobal
        this.CampaignObject = db.Campaigns.SingleOrDefaultasp.net(x => x.CampaignID == campaignID);

        //Populate Contact Status Lists
        this.UnsubmittedContactIDs.AddRange(from x in this.CampaignObject.CampaignContacts
                                                 where x.ContactSubmissionID == null
                                                 select x.CampaignContactID);

        this.SubmittedContactIDs.AddRange(from x in this.CampaignObject.CampaignContacts
                                               where x.ContactSubmissionID != null
                                               select x.CampaignContactID);

        this.ProcessedContactIDs.AddRange(from x in this.CampaignObject.CampaignContacts
                                               where x.ContactSubmissionID != null
                                               && x.ContactSubmission.DateProcessed != null
                                               select x.CampaignContactID);
    }

    #endregion

    #region Public Static Methods

    public static void WriteLogEntry(int? campaignID, int? contactSubmissionID, int? scheduledDropID, int? userID, string activityDescription)
    {
        ActivityLog activityLog = new ActivityLog();
        activityLog.CampaignID = campaignID;
        activityLog.ContactSubmissionID = contactSubmissionID;
        activityLog.ScheduledDropID = scheduledDropID;
        activityLog.UserID = userID;
        activityLog.Text = activityDescription;
        activityLog.CreatedDate = DateTime.Now;

        using (MailCampaignManagerEntities db = new MailCampaignManagerEntities())
        {
            db.ActivityLogs.AddObject(activityLog);
            db.SaveChanges();
        }
    }

    #endregion
}

Answer 1

The implementation should usually be "okay", but...

You should mark the object as [Serializable], depending on the SessionStateModule that you have configured. Web farms or a web gardens typically use modules other than the InProc one, and they use serialization to store the session state. Otherwise, it looks okay for your object to be serialized, so no problems there.

You may want to check if there is currently any session at all, or you could get a NullReferenceException. That would probably mean a misconfigured application however, or a call too early in the life cycle.

Your application might allocate an AppGlobal object twice for a single session due to a race condition that you have in the way you check and set the Session variable. I don't think even that is currently an issue, but it's something to keep in mind if you want to include more fancy stuff. To prevent it, you can use lock like this:

public class AppGlobal
{
   private static object _syncRoot = new object();

   public static AppGlobal Instance
   {
       get
       {
           HttpSessionState session = HttpContext.Current.Session;

           lock (_syncRoot)
           {
               if (session["AppGlobalInstance"] == null)
               {
                   session["AppGlobalInstance"] = new AppGlobal();
               }
           }

           return (AppGlobal)session["AppGlobalInstance"];
       }
    }     
}

If you ever want to store anything inside the object that prohibits serialization, and you need to support other SessionStateModules, you could store your instances in a collection that uses a classic Singleton pattern (here is a good implementation). ConcurrentDictionary would probably be a good one. As the key, you could use something unique that you do store in your Session, like a GUID. You would need to remove the entry from the collection when the session ends in any way.

Answer 2

That looks like a valid singleton pattern. It also looks like a very big object to store in Session. You might run into performance and memory issues if you have a lot of users.

Answer 3

Objects in Session are already unique, meaning same key refers to one instance of object.

Answer 4

The Session object essentially comes from a dictionary of singleton objects. So, when you reference the Session object, you are already benefiting from the singleton pattern behind the scene. Therefore, you don't need to re-invent the wheel by placing the Session object into a singleton pattern.