If you have been reading this blog lately you may have noticed that I’m currently working on a project where I chose Linq to Sql as my data-source, inspired by the IQueryable<T> Repository Rob Conery introduced in his MVC Storefront series.

The basic idea of the IQueryable<T> repository is to have the repository return a IQueryable list of C# domain objects that can then be filtered, queried, parsed at higher layers of the application. So things like paging, filtering etc (all business concerns) can be applied to the query at a later stage instead of having to propagate all of these requirements down to the Repository (Ayende wrote somethinggreat on the death of Repository you should check out).

So my business code would call the repository for all objects and then apply logic to it:

I loved it. Not having to propagate concerns like paging and filtering to the DAL was awesome, and since the interface is so damn simple I very quickly came up with decorators that did error handling, caching and logging at the DAL level.

Since I’ve become a dependency injection nut, I then came up with a injectable datacontext so my repositories don’t have anything to do with the data context creation (thus sparing me the configuration concerns in that class).

You see, the context gets injected and besides the query there is nothing in the repository, SRP .. check.

Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.

And this is where it blew up in my face, having multiple threads access the repository leads to some nasty race conditions for the datacontext, and I found no sane way of dealing with this at the DAL level.
Try this:

The same query as before, but two threads that share the same repository, therefore sharing the same datacontext. Once started, the whole thing will blow up with a InvalidOperationException stating that the connection is closed.

I didn’t bother to go into the DataContext source and check out why they are closing the connection, but apparently after the query is executed it takes some time for the context to “recover” and be able to accept a new query.

I immediately tried to solve the problem by adding a lock on the datacontext in the repository class (since the contexts are pooled, it was the only thing that made sense since I don’t need to lock all connections, just the one I’m currently using).

I intentionally said I tried, because it didn’t work. The lock gets executed alright, but the query isn’t run inside the lock{} but rather at the calling code, in my business class (the power of deferred execution). So the only way to prevent a race condition for my datacontext would have been to add locking to the business code:

Omg right? So, besides the fact that I can’t guarantee that two repositories don’t use the same datacontext (and therefore racing against each other), I just opened the Pandora's box of possible errors (give me a month and I’ll forget the locking at least 3 times).
Also, it’s just painful to see an implementation detail of the data access layer leak into the business code for no apparent reason.

And the only way I found on how to solve that problem was to supply a new datacontext to every query, so I get rid of the whole locking. I did so by injecting a datacontext factory into the repository and call the factory every time I execute a query.

This fixed the issue for now, butI don’t feel too good about the solution. Creating new datacontext object for every query somehow feels wrong, and I’d love to hear suggestions from you on how to change that.

Some of you may already know ELMAH, a great error logging tool that hooks into ASP.NET applications logs all exceptions encountered during runtime.

There are some great articles on how to set up ELMAH for traditional ASP.NET articles in their wiki, but ASP.NET MVC is not mentioned (it’s really simple nonetheless).

Step 1: Referencing the assemblies

First, grab the latest binary release of elmah from the project’s page and extract the \bin folder to your application folder. I’m a huge fan of having all external assemblies in a lib folder besides the app, so to my delight elmah requires no installation, you just have to drop the 3 files in \bin to your lib folder and reference the Elmah.dll from within your app.

Step 2: Edit your web.config to call ELMAH

First add the following code to your <configSections> to make ELMAH read it’s configuration from web.config:

This will reroute all requests to a file called elmah.axd to the ELMAH error-overview page. So when you want to look at the list of errors you’ll access http://server/elmah.axd . The name doesn’t matter, feel free to rename it, but be aware that the extension has to be mapped to the ASP.NET pipeline inside IIS (so naming it .html wouldn’t work if not configured correctly).

At last add the ELMAH logging module to your <httpModules> section:

<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>

Step 3: Configure ELMAH

I’d suggest you read the wiki articles on how to configure ELMAH correctly, but for my application I chose to log all errors to a XML file by simply adding this code to the web.config:

This instructs ELMAH to create xml files in your App_Data directory (so make sure the ASP.NET process has sufficient access rights to that folder) and generate output like this:

Step 4: Configure routing

Up until now we were 100% true to the normal configuration routine for normal ASP.NET applications, there is only one slight adjustment to making it work in MVC.

You need to allow the requests to the ELMAH frontend (elmah.axd in this example) to pass through the MVC routing logic unchanged so that it gets handled by normal ASP.NET behind MVC. This is as trivial as adding a ignore route to your routing table in Gobal.asax.cs:

Once all the above is done, you’ll see all unhandled exceptions that result in a yellowscreen-of-death be also logged into the XML files inside your App_Data and you can then watch them remotely by accessing http://server/elmah.axd. You’ll get a rather nice overview page like this one:

Having no errors in the first place is a way to make this work obsolete, but it’s nice to know for sure that your users aren’t encountering errors when using your site. There are advanced configuration guides in the wiki on how to set up email notification and security, but I’ll leave that to the project wiki.

I made it a habit to always program towards an Interface if possible. So all my lists in code are of type IList<T> and the IList<T> lacks the .Sort() method of the List<T> class.

Usually this isn’t a problem since there is LinQ’s .OrderBy to save the day. But this time my class is too generic for that so I have to fall back to good old OO principles with comparer classes etc.

Now, my problem is that I need a simple IList that is sorted on insertion. I first thought, no problem I’ll just use the SortedList<Tkey, Tvalue> that’s already in the framework. But there is always a catch: SortedList is more of a dictionary than a list. Duplicate key items aren’t accepted, there is no collision handling. Trying to insert a duplicate key will result in a ArgumentException:

Since LinQ stepped onto the stage I rarely think about sorting, selecting etc any more. A simple IEnumerable<T>.OrderBy(p => p.Id) does the trick quite nicely.

But, there are cases where I wanted the list to be sorted in itself, and so I turned to the SortedList and SortedDictionaryclasses in the System.Collections.Generic namespace.

Usage is incredibly easy, they are just ordinary IDictionary<Tkey, Tvalue> implementations that behave in every way as expected (no duplicate keys mind you), but in order to use them effectively you should be aware of some minor things about comparers.

Internally both collections will use a TreeSet structure that sorts itself by using a given IComparer<TKey> to determine their sort order. So all we need to do is add some pixie dust as the IComparer<TKey> to interfere with the order.

And since I don’t want to write one IComparer<T> for every type in the framework, I did a find-inheritor search with Reflector on the IComparer<TKey> interface only to discover that there is only one implementation: StringComparer. All other types get compared either by a custom comparer or the following call:

Comparer<TKey>.Default;

The static method Default will return an appropriate comparer for the given TKey type (taken from the IComparable<T> interface that has to be implemented by TKey).

So, in order to reverse the list, we just have to supply a custom comparer that reverses the default comparer. (Since the LinQ .Reverse() method is out of the question :)).

And that’s rather easy once you know where to get the default comparer from:

My little brother bought himself the RPG epos Gothic III and came to me with a rather interesting problem: After a clean install the game wouldn’t start in full screen mode but rather restrained itself to a 1024x768 window.

I found the glitch pretty fast, a configuration file caused it:

fullscreen = trues

Changing the trues to true did the trick and everything went smoothly.

Bugs are quite common in computer games, but how on earth someone can ship a game with a so apparently wrong configuration file is beyond my knowledge. Sorry to say, but someone failed when a vital config file contains a typo!