I'll be giving a talk on Monorail tomorrow evening, at Microsoft offices in Ra'anana.

Registration details are here:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032402276&Culture=he-IL

I'll try to upload the presentation beforehand to here (no promises though).

See you there :)

I like the 'smell' of the airport.

I'll be spending the following week on a snowboard, and the guesthouse I'll be at has no internet access, so if you see me ignore emails, castle's usergroups, facebook 'join XYZ group' invitations etc., don't take it personally.

Except the facebook thing, I rarely join any group, cause or application. only friends requests (from people I know), thank you.

I might have a little time to post some more while waiting in the airport lounge, but don't count on that.

The bug:

Weird behaviours regarding session management

The blame:

(within session access wrapper static class):

private static IDictionary session;
...
if (session == null)   session = new SessionAdapter(HttpContext.Current.Session);
...

so the first time the last line is called, the then-current-session is stored in a static variable, thus the first session is always referenced even for newer sessions.

The reason for the above code being present in the first place is that:

public static void SetSessionTo(IDictionary newSession)
{
    session = newSession;
}

So that tests that a stubbed ‘session’ could have been injected into the session-wrapper-static-class thingie.

Clearly, the implementation was wrong.

The fix:

now the code looks like this:

private static IDictionary stubbedSession;

static IDictionary Session
{
    get { return stubbedSession ?? MonoRailHttpHandler.CurrentContext.Session; }
}

And these were 60 seconds on careless coding.

Ken, the careless coder