Question

I’m on an ASP.Net 2.0 project, in C#. I have some data that gets stored in session state. For ease of use, it is wrapped in a property, like this:

protected IList<Stuff> RelevantSessionData
{
    get
    {
        return (IList<Stuff>) Session["relevant_key"];
    }
    set
    {
        Session["relevant_key"] = value;
    }
}

Getting and setting the value works exactly as you’d expect. If I want to clear the value, I just set it to null, and there are no problems. However, in another developer’s page, he calls the collection’s Clear() method. I thought this would be a bug, but it seems to work, and I don’t understand why. It works like so:

Debug.WriteLine(RelevantSessionData.Count);    //outputs, say, 3
RelevantSessionData.Clear();
Debug.WriteLine(RelevantSessionData.Count);    //outputs 0

Why does this work? My naive expectation would be that the middle line loads the serialized value from session, deserializes into an object, calls Clear() on that object, and then lets the unnamed object fall out of scope. That would be a bug, because the value stored in Session would remain unchanged. But apparently, it’s smart enough to instead call the property setter and serialize the newly changed collection back into session.

This makes me a little nervous, because there are places in our legacy code where property setters have side effects, and I don’t want those getting called if it’s not intended.

Does the property setter always get called in a situation like this? Is something else going on? Or do I completely misunderstand what’s happening here?

[Added to explain answer]
It turns out did misunderstand. I knew that objects stored in Session must be serializable, and based on that I made too many assumptions about how the collection behaves internally. I was overthinking.

There is only one instance of the stored object (my IList). Each call to the getter returns a reference to that same instance. So the quoted code above works just as it appears, with no special magic required.

And to answer the title question: No, setters are not called implicitly.

Answer 1

Yes, you are right, this would be a bug if your setter/getters were serializing/deserializing the objects. But this is not the case. Instead you are passing based on reference.

So what’s basically happening is that the first line in your example gets the item via the get, and Count is called based on that. Then the seccond line is going out and calling get again, returning the same object, running clear, and then the third line is doing the same as the first.

If you had written your setter/getter something like this, you would have a “bug”

protected IList<Stuff> RelevantSessionData
{
    get
    {
        return (IList<Stuff>) JSON.ConvertFromString(Session["relevant_key"]);
    }
    set
    {
        Session["relevant_key"] = JSON.ConvertToString(value);
    }
}

In this case, a new object would be created and for each call to the get block. But since your example above is simply passing around the reference to the same object, you’re not going to see this “bug”.

And I say “bug” since it’s not really a bug, it’s just more of a misunderstanding of what’s happening behind the scenes.

I hope this helps.