RichP's Blog

I have been messing around with Windsor recently and I thought I would jot down some notes. I have also add some code samples to demonstrate various aspects of Windsor. See code samples at the bottom of the post.

Dependency Injection / IOC

Before going any further make sure you understand the concepts of IOC and Dependency injection. Mr Fowler does quite a good job of explaining things here:
Inversion of Control Containers and the Dependency Injection pattern.

Why use Dependency Injection / IOC

• Flexibility
• Ease of testing

What is an IOC container

A facility that helps to wire up classes which follow the IOC / dependency injection principle
I like to think of it as an object factory on steroids.

Container Patterns

There are two main container patterns in use today:

• Service Locator
• Dependency Injection

The Windsor Container

The Windsor container is on of several good IOC containers. Its been around for a while and it offers all of the main areas of functionality that you would expect from a container. For more info see: Inversion of Control Containers and the Dependency Injection pattern.

How to use Windsor

• Design code using the Dependency Injection Pattern
• Configure the Windsor Container
• Use the container to resolve object instances.

Code Samples

Click here: IOC Code Samples to download four projects which demonstrate the following:

• How to use Windsor
• How to use Windsor including dependencies and overrides
• How to configure Windsor using a config file
• The default singleton instancing adopted by Windsor

I hope this is useful…..

I recently ran into some problems with ASP.Net session state with a SQL server provider. At times the SQL Database is being hit extremely hard with updates locks and reset timeout events.

Consequently I have spent a fair amount of time researching the optimisation of session state and I thought I’d write up some of my findings for future reference.

Setting up the SQL Session State Provider

I am not going to go into setting up the SQL Session state provider, for more information ion this see: HOW TO: Configure SQL Server to Store ASP.NET Session State.

A bit about the SQL Server Session State DB

The State DB is database provided by Microsoft to manage session state. Session state data is stored in a table called: ASPStateTempSessions. This table is managed via a number of stored procedures, in particular:

• TempGetStateItem3 (there are 3 versions of this suffixed: 1,2 or 3). This proc retreives session data without locking the session row.
• TempGetStateItemExclusive3 (there are 3 versions of this suffixed: 1,2 or 3). This procedure retreives session data with an exclusive lock on the row.
• TempInsertStateItemLong (there are 2 versions of this suffixed: Long or Short). Inserts data into the session DB.
• TempResetTimeout
• And several others………

It is worth mentioning here that the State DB maintains its own locking mechanism. The ASPStateTempSessions table has a column called “Locked”. If the calling client requires an exclusive lock on the session row (i.e. TempGetStateItemExclusive) and this column is set to “1″ then the request will be blocked until the lock is released.
Configuring Session State at the page level
The easiest way (and perhaps) the only way to configure SQL session state is to use the page level directive:

[sourcecode language='c#']
|##@ Page EnableSessionState= ……
[/sourcecode]

This directive has 3 modes: True, False and Readonly. I would recommend that wherever possible this is set to “False” or “Readonly” as it reduces traffic to the Session DB. Only pages which need to update, add or remove session state data require this directive to be set to “True”.

The Impact of the EnableSessionState directive

I spent several days analysing a sample ASP.Net application configured to use a SQL session state provider. Using SQL Profiler I analysed the impact on the session DB of these pages directives. My observations were as follows:

EnableSessionState=”True”

Enabling session state as above has no impact on the Session DB until a session ID is allocated (typically by adding some session state). However, once a session ID has been allocated and is flowing backwards and forwards from the browser, the following stored procs will be invoked against the Session DB on every request:

• TempGetStateItemExclusive3
• TempReleaseStateItemExclusive

These stored procs are called on each request, even if the page does not actually do anything with session sate.

If the page does actually manipulate session state, then the following stored procs are invoked:

• TempGetStateItemExclusive3
• TempUpdateStateItemShort (or one of the other similar proc’s ….)

EnableSessionState=”False”

With this setting configured, the session DB is not hit. However surprisingly if the Session ID is active, the following following calls are made to the Session DB for each request:

• TempResetTimeout

Admittedly this is much lower impact than for full session mode, but I did find it surprising that that Session DB is hit at all. Further investigation revealed that the purpose of this call is simply to keep the session alive.

EnableSessionState=”ReadOnly”

The final option is the “ReadOnly” mode. As it says on the tin this allows the page to read session data but not to update it. Once again this mode has a lower impact that the full session mode. Once again, accessing a “ReadOnly” page when there is no active session has no impact on the Session DB. When a session is active the following stored proc’s are invoked:

• TempGetStateItem3

Other Findings

What surprised me most of all is that once a session is active the session DB is hit for every page request, even when EnableSessionState is set to “False”. This behaviour was particularly problematic when a page is accessed from an Ajax call. Worse still, is that even when you clear out all of your session state (Session.RemoveAll()) and attempt to kill off the session (Session.Abandon()) the SessionID lives on and the Session DB continues to be impacted. I did find a work around for this as detailed below:

Killing off a Session

As mentioned above, cleaning out your session data and abandoning the session is not enough to properly kill of a session. To kill of a session you need to tell the browser to lose the session id. You do this by sending a session cookie with the response. To terminate a session do the following:

• Call Session.RemoveAll();
• Call Session.Abandon();
• Call Response.Cookies.Add(new HttpCookie(“ASP.NET_SessionId”, “”));

That’ll do it….

SessionIDManager

I also spent some time investigating using a custome SessionIDManager as discussed in this article: Fast, Scalable, and Secure Session State Management for Your Web Applications.

At first I thought that I might be able to used this handler to stop certain page requests from accessing the session DB. I did manage to implement one of these, but for me it didn’t quite work in the way the article suggested. I am assuming that this article is slightly out of date as the “GetSessionID” method is not overrideable. I did manage to override the CreateSessionID method, but this method is only called when creating new sessions. If the browser already has a session ID from a previous page request, this method is not invoked…..

Conclusions

Based on my findings, I would recommend the following:

• Whenever possible avoid using session state.
• Use the EnableSessionState page directive appropriately and bear in mid the default behaviour is EnableSessionState=True.
• If your application has used session state but no longer requires it, (e.g. in a shopping cart the user has added some items to a basket and then removes them all) end the session properly as described above.

Other suggestions

Based on other articles that I have read I would also suggest the following:

• Keep session storage to a minimum and keep the data light.
• Don’t store complex object graphs as the seizialization can be expensive.
• If you do need to store object graphs use the serialization attributes to reduce overhead.
• Consider implementing custom serialisation logic for complex object graph.

Useful Links

Here are some links that I found useful when researching this:

• Fast, Scalable, and Secure Session State Management for Your Web Applications
• SessionStateModule Class
• Underpinnings of the Session State Implementation in ASP.NET

Background

Sometimes it is desirable to configure a WCF service to support on more than one endpoint. Implementing this on a service which is hosted outside IIS (in a console app or Windows service say) is very straight forward and logical. Surprisingly achieving this on a service which is hosted in IIS is just as easy – but it is slightly less logical.

Example

Say for example I had a simple WCF service which I want to host in IIS and support the basicHttpBinding and the wsHttpBinding. All I need to do is to add two endpoints in the config, one for each protocol, see:

[sourcecode language='xml']

[/sourcecode]

The only thing to note is that the endpoints cannot have the same address, notice that the wsHttpBinding endpoint uses the default address (the IIS route path e.g. http://localhost:3985/Service1.svc) and the basicHttpBinding use the “basic” address which will resolve to http://localhost:3985/Service1.svc/basic or something similar.

For more info see: Multiple Endpoints.

I am a big believer in Test Driven development. I am also an avid user of mocking Frameworks I having used the excellent Rhino Mocks framework in the past and am currently using the NMock framework as this is the preference of my current client.

Anyway, the other day I was testing some code was struggling to work out how to test it effectively. The code that I was trying to test is shown below:

[sourcecode language='c#']
public interface IDataGateway
{
int AddMessageToQueue(Message message, IList customerIds);
}

public class MessageHandler
{
private IDataGateway _dataGateway;
public MessageHandler(IDataGateway dataGateway)
{
_dataGateway = dataGateway;
}

public int SendMessage(Message message, IList customerIds)
{
IList newCustomerIds = customerIds.ToList().ConvertAll(c => int.Parse(c));
int messageCount = _dataGateway.AddMessageToQueue(message, newCustomerIds);
return messageCount;
}
}
[/sourcecode]

The code above is fairly simple. I won’t discuss ways to improve it as it is really designed to illustrate a point.

As I am a Mockist I would like to test that given an input message and list of customer ids the AddMessageToQueue method on the _dataGateway object is called with the correct parameters.

NMock can help me with this because it allows me to Mock the _dataGateway interface and then inspect the interactions between my MessageHandler object and _dataGateway. The problem is that I can’t test this interaction in the bog standard NMock way because my I have no control over the newCustomerIds list that is created inside this method. Enter the Custom Matcher.

So, I developed a custom list matcher and used this to help define the expectation on the _dataGateway mock. The code is listed below:

[sourcecode language='c#']
public class ListMatcher : Matcher
{
private IList _theList;

public ListMatcher() : this(null)
{
}

public ListMatcher(IList theList)
{
_theList = theList;
}

public override void DescribeTo(System.IO.TextWriter writer)
{
writer.Write(“< ");
writer.Write(this.GetType().Name);
writer.Write(">“);
}

public override bool Matches(object o)
{
bool itMatches = false;
List inList = o as List;
if ((inList != null) && inList.Count == _theList.Count)
{
itMatches = true;
for (int i = 0; i < _theList.Count; i++)
{
itMatches = itMatches && _theList[i].ToString() == inList[i].ToString();
}
}

return itMatches;
}
}
[/sourcecode]

This list matcher allows NMock to compare the elements of two lists. You pass the expected list into the constructor on instantiation and this is used to compare against a list passed in a method call.

The code snippet below shows how to wire up the unit test.

[sourcecode language='c#']
[Test]
public void SendMessage_ExpectCorrectInteractions()
{
Mockery mockery = new Mockery();
IDataGateway dataGateway = mockery.NewMock();

MessageHandler handler = new MessageHandler(dataGateway);

Message message = new Message();
List customerIds = new List(new string[] { “1″, “2″, “3″ });
List expectedCustomerIds = new List(new int[] { 1, 2, 3 });

Expect.Once.On(dataGateway).Method(“AddMessageToQueue”).
With(Is.EqualTo(message), new ListMatcher(expectedCustomerIds)).Will(Return.Value(6));

handler.SendMessage(message, customerIds);

mockery.VerifyAllExpectationsHaveBeenMet();
}
[/sourcecode]

That’s it really, hope that this proves useful to somebody!