Insert Catchy Title Here

SSMS Execution Plan – Insert Index Here

Bill Pierce — Wed, 24 Dec 2008 18:52:59 GMT

I was troubleshooting a performance issue with a particular stored procedure in our application. Myself being a developer my thought process is DB Performance Issue => Add an Index. That is about the extent of my knowledge and when that doesn’t work I stop questioning what exactly it is that a DBA does :) To figure out where an index is needed I would usually zero in on WHERE clauses and make sure any filtered columns are indexed. The problem is this stored procedure was ginormous and called several other sprocs on its path to destruction. So, I thought I’d check out the execution plan. So I was using SSMS 2005 because that is what was installed on the machine I was remoted in to. Problem was the execution plan looks like it was a collaboration of Dr. Seuss and MC Escher. I didn’t want to tie up the server so I saved the execution plan and copied it down to my local machine (the plan was over 1MB so you feel my pain). I tried to grok the plan for a while but didn’t have any luck so I decided to run the sproc with the troublesome parameters on my local box to see if the performance was bad locally. I run SSMS 2008 on my local machine and when I ran the query with the execution plan turned on, lo and behold, the Execution Plan told me in bright green letters “Hey idiot stick, you are missing an index on Table X with Columns (Y and Z) Include (A, B, C).” Needless to say I thought this was an awesome feature and sure enough, adding the index as directed solved the performance problem.

If you are running SSMS 2008, you can repro the behavior by running the below script to create some data:

CREATE TABLE IndexMe(Guid UNIQUEIDENTIFIER NOT NULL)
GO

SET NOCOUNT ON

BEGIN TRAN

INSERT INTO IndexMe(Guid)
VALUES(NEWID())

DECLARE @i INT; SET @i = 0;

WHILE @i < 21 BEGIN
  INSERT INTO IndexMe(Guid)
  SELECT NEWID() FROM IndexMe
  SET @i = @i + 1
END

COMMIT TRAN
GO

Now, turn on the Execution Plan in the Query Analyzer and run this query:

SELECT * FROM IndexMe WHERE Guid > '889327B7-966E-4288-A459-EEE4EEA9D109'

You should be presented with something like so:

The “Missing Index” tells you exactly what you need to do for your query to suck less.

Using Perforce Visual Merge with Team Foundation Server

Bill Pierce — Wed, 24 Dec 2008 17:45:54 GMT

The best way to handle merging is to not do it at all :) Merging can be a very painful process, especially if you are using the wrong tools. I was a long time user of Perforce for source control and this company’s great tools made merging very straight forward. I have now transitioned to a Team Foundation Server 2008 environment and while this tool is growing in usefulness, it still lacks in a few areas. Luckily TFS can be configured to use existing merge tools, including Perforce Visual Merge (P4merge) from Perforce.

You can configure TFS to use a different merge tool by running the following from a Visual Studio Command Prompt:

tf diff /configure

This brings up a dialog like so

If you don’t already have a Merge operation line, you can add one, otherwise just modify the existing one and make it look like so:

If you are curious you can click the right-arrow to see what each command line argument represents. You may be wondering why the command is for p4merge.bat instead of the executable. P4Merge expects the original file, branch 1 file, branch 2 file, and the final merged file to all exist for it to operate properly. Unfortunately, TFS does not create the merged file before it invokes the merge tool. To work around this I created a simple batch file that will create the merge file at the path provided (%4) then invoke p4merge.exe. Simply paste the following into p4merge.bat and you are ready to rock.

@ECHO OFF
COPY /Y NUL "%4"
START /WAIT /D "C:\Program Files (x86)\Perforce" p4merge.exe "%1" "%2" "%3" "%4"

Blogs I Follow

Bill Pierce — Tue, 21 Oct 2008 17:18:35 GMT

Justin Etheredge posted a list of blogs that he follows. He also posted a snippet of LINQ that converted his OPML file to a simple unordered HTML list. He encouraged his readership to let him know if there are any really good blogs he was missing. I was curious to see which blogs he reads that I have not yet subscribed to. I tweaked his LINQ slightly to output blogs that were in his OPML file, but not in mine.

var doc1 = XDocument.Load("http://media.codethinked.com/downloads/Opml.xml");
var doc2 = XDocument.Load("http://services.newsgator.com/ngws/svc/opml.aspx?uid=134891&mid=1");

var result = new XElement("ul",
  from d1 in doc1.Elements("opml").Elements("body").Elements("outline")
  join d2 in doc2.Elements("opml").Elements("body").Elements("outline")
    on d1.Attribute("htmlUrl").Value equals d2.Attribute("htmlUrl").Value into d3
  from d2 in d3.DefaultIfEmpty()
  where d2 == null
  select 
    new XElement("li", 
      new XElement("a", 
        new XAttribute("href", d1.Attribute("htmlUrl").Value), d1.Attribute("text").Value
      ), 
      " ", 
      new XElement("a", 
        new XAttribute("href", d1.Attribute("xmlUrl").Value), "RSS"
      )
    )
  );

using (var xw = XmlWriter.Create("diff.xml", new XmlWriterSettings { Indent = true }))  
{   
  result.WriteTo(xw);
}

diff.xml will contain blogs present in doc1 but not present in doc2. This is by no means perfect so don’t cry if it includes a few entries present in both or doesn’t work with your OPML. You could easily see which blogs both Justin and I read by changing the where clause.

Several readers wrote to Justin asking how he could possibly keep up with that many blogs. I only spend about 20 minutes a day reading through new posts. Only autonomous coding machines post everyday, so as long as I don’t lapse for more than a day or two it isn’t a problem keeping up. I also skim long posts and flag them for a more thorough reading later. Most of my subscriptions focus on .Net development but I have a few outliers like Zed Shaw’s blog. It can make for an extremely entertaining read (as long as you are not the subject of his attentions :).

NHibernate ProxyGenerators 1.0.0 Beta Released

Bill Pierce — Tue, 07 Oct 2008 20:48:00 GMT

Read about it at NHForge.org

del.icio.us Tags: nhibernate proxygenerators

Please Explain the Following

Bill Pierce — Mon, 06 Oct 2008 21:36:38 GMT

Can someone please explain how this is possible?

Introducing NHibernate ProxyGenerators

Bill Pierce — Tue, 23 Sep 2008 05:06:12 GMT

NPG is dead. Long live NHPG. In an attempt to not duplicate information, I’m going to put most of the technical details on NHForge. I will highlight here the improvements that have been made to NHPG since its original inception.

Renamed NPG.exe to NHPG.exe (Duh)
Improved error handling and informative error messages
You can now provide several mapping assemblies at once
Removed dependency on ActiveRecord. Don’t cry though, you can still use it on AR assemblies.
Now with more cowbell
I was given the directive to support multiple proxy generation frameworks and while the design is there, you can currently get your proxies in any color, as long as it’s black. (By color I mean framework and by black I mean DynamicProxy2)
Improved unit test coverage. (By improved I mean there was none and now there is some)
Improved runtime logging (See previous bullet)
The code now looks like a slightly more intelligent monkey wrote it
Intermediate files are now cleaned up properly
Proxy assembly version is now synchronized with mapping assembly version
Working example now distributed with source

Where you can help.

Additional proxy generation implementations
The generation is dog slow
The need for intermediate files mentioned above could probably be avoided by someone who knows what they’re doing

Enjoy, and please proxy responsibly.

del.icio.us Tags: NHibernate,proxy generator,npg,nhpg

Windows Live Writer on Server 2008

Bill Pierce — Mon, 22 Sep 2008 13:46:00 GMT

del.icio.us Tags: live writer server 2008

This was way harder to find than it should have been. There are various posts on downloading a Technical Preview that installs on Server 2008. This installation told me it would expire shortly and it also appeared to be an older version (v12). Some comment trolling turned up a German Windows Live Writer Blog that had what I was looking for. The link at the very bottom installed what appears to be the latest beta for Windows Server 2008 x64.

Poor Man's Shards in NHibernate

Bill Pierce — Sun, 08 Jun 2008 22:35:56 GMT

Another loosely coupled post on Going to Production with MonoRail.

One thing I haven't stressed in recent posts is the absolute necessity to thoroughly test and understand the implications of your modifications when you start pushing a framework outside of the box. In my post on Advanced Dependency Injection with Castle Windsor I lightly touched on the lifestyle implications of my patch to the code. The same warning covers today's post when we start jimmy jacking with a custom connection provider in NHibernate.

If you've been following along you know that for various reasons we host multiple clients on a single instance of our B2B web application. For other various reasons we like to keep the data for each client segregated into separate databases. We use NHibernate for persistence ignorance so that seemed to be the logical place to start when attempting to segregate client data. When I was doing my research it became apparent that at a high level I was trying to implement a horizontally partitioned database. In my case, partitioned by client. Hibernate supports horizontal database partitioning through Shards. Dario Quintana is in the process of porting Shards to NHibernate, but I don't believe it is quite ripe yet. Shards appears to address all of the nuances and edge cases that would reveal themselves when attempting to logically split data. My needs were much cruder and I was willing to sacrifice a fully functional implementation (see first paragraph above though).

Each client hosted in our application has their own configuration file. Within this file is a database connection string that points to the database for the particular client. As long as the database structure of each database is identical, NHibernate is cool with that. What I ended up implementing is a custom IConnectionProvider that would load the current client's configuration, read the connection string, and create a connection using that, rather than the connection string that would normally be read from your hibernate.cfg.xml file. The sample code gets the job done.

namespace My.Application
{
  public class ClientConfigurationConnectionProvider : DriverConnectionProvider
  {
    public override IDbConnection GetConnection()
    {
      string clientId = ClientIdProvider.Get();

      if (null == clientId)
      {
        return base.GetConnection();
      }

      ClientConfiguration clientConfiguration = ClientConfigurationManager.GetByClientId(clientId);
      string dbConnectionString = clientConfiguration.DbConnectionString;
      if (string.IsNullOrEmpty(dbConnectionString))
      {
        return base.GetConnection();
      }

      IDbConnection conn = Driver.CreateConnection();
      conn.ConnectionString = dbConnectionString;
      conn.Open();
      return conn;
    }
  }
}

Very straight forward. By inheriting from the built in DriverConnectionProvider, most of the hard work is done for us. To tell NHibernate to use our connection provider, a small change to the configuration file is required:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <!-- <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property> -->
    <property name="connection.provider">My.Application.ClientConfigurationConnectionProvider, My.Application</property>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=MyApplication;Trusted_Connection=True;</property>
    <property name="show_sql">true</property>
    <mapping assembly="My.Application" />
  </session-factory>
</hibernate-configuration>

Remember what I said though, depending on your database structure, and the features of NHibernate you choose to take advantage of, bad and unexpected things could happen with this implementation, so do your testing.

Runtime Dynamic Actions in MonoRail with Windsor

Bill Pierce — Sat, 07 Jun 2008 20:40:30 GMT

Another loosely coupled post on Going to Production with MonoRail.

The ability to customize every aspect of an application Lego style is great, but there will always be client needs that are absolutely off the wall. Not a customization of an existing component, but something so specific and unique to the client's domain that it cannot be encapsulated into something reusable. My mind struggled with the paradox, how do I architect the ability to insert non-reusable functionality in a reusable way? Mike Nichols put me on the path to my solution.

Dynamic Actions are a feature of MonoRail that allow you to decouple an action from a controller. This sounds pretty simple but when you read through the documentation and the many ways that developers are putting them into practice, Dynamic Actions reveal their true power. The first part of my solution: completely custom functionality is simply implemented by a class that implements IDynamicAction. Each piece of custom functionality corresponds to a dynamic action. The next question is how do I expose this functionality to the Client? How do I ensure that this functionality is only exposed to the Client that paid for it?

I haven't yet posted about how we manage configuration for each client, but essentially we have an INI file (cringe! gasp! moan!) for each client hosted on a particular server. A sample section of the INI file for the Contoso client would look like so:

[Actions]
DoWork=ContosoDoWorkAction
DoWork2=ContosoDoWork2Action

The key (DoWork) represents the name of the action, the value (ContosoDoWorkAction) is the name of a class that implements IDynamicAction and the logic for the custom functionality required by the client. Actions are loaded into the child container for the Client during application startup. Now we need a controller that we can attach these actions to at runtime. This is achieved using the code sample below:

namespace My.Application
{
  public class CustomController : Controller
  {
    public CustomController(IKernel kernel)
    {
      ClientConfiguration clientConfig = ClientConfigurationManager.GetCurrent();

      NameValueCollection actions = clientConfig.Actions;

      foreach (string actionName in actions.AllKeys)
      {
        string actionTypeName = actions[actionName];
        Type actionType = Utility.GetImplType(actionTypeName);
        DynamicActions[actionName] = (IDynamicAction)kernel.Resolve(actionType);
      }
    }
  }
}

So simple it should be criminal. With the configuration sample above and the CustomController implementation, we now have valid URLs of:

https://contoso.myb2bapplication.com/custom/DoWork.rails

https://contoso.myb2bapplication.com/custom/DoWork2.rails

At the same time, by the nature of our child container configuration magic, the following URLs would be invalid:

https://fabrikam.myb2bapplication.com/custom/DoWork.rails

https://fabrikam.myb2bapplication.com/custom/DoWork2.rails

This is because the actions are only available to the client for which they were configured. By the same token I can disable an action by commenting out the line in the configuration file.

Who's your daddy paradox?

Advanced Dependency Injection with Castle Windsor

Bill Pierce — Fri, 06 Jun 2008 20:15:56 GMT

Another loosely coupled post on Going to Production with MonoRail.

Many moons ago I wrote a post about dynamically resolving a component from the Castle container based on runtime parameters. There was some discussion about the limitations of the approach (the biggest is that all components that require customization or components that have dependencies that require customization must be Transient) but overall it accomplished my goals at the time. To summarize, my implementation allowed you to load multiple components that implement the same service (say an IOrderValidator) and also allowed you to provided a predicate that would be invoked when your code resolved an IOrderValidator to allow you to choose which specific implementation to return. The idea was that you could have multiple clients hosted on a single instance of your application, each requiring their own order validation logic. Using a runtime parameter (like the host header) your provided predicate would resolve the IOrderValidator associated with the particular client's requirements. This implementation worked for some time but had a few limitations, namely all components for all clients had to be loaded into the same container. This ended up being a tad unruly to manage. There were also some limitations on the order in which components were loaded into the container, which was problematic when auto configuring the container via code or something like Binsor.

I set out for a better solution that addressed my new requirements and ran into the related issue of scoped containers that had been proposed on the Castle mailing lists. Scoped containers have a slightly different use case and requirements but overlapped some with the approach I ultimately settled upon. My container contains over thirty (30) components that make up the core functionality of the application. Some of these components have dependencies on other components and all of this management, injection, and resolution is handled nicely and elegantly by the container. Lets say for a particular client I need to customize one of the these components. But the component in question has dependencies on three other components, whose functionality I do not need to customize. I need a way to add my customized component to the container, but still resolve its dependencies from the core set of components. The answer to my problem came in the form of Child Containers.

A child container is just like your standard container only that it has an associated parent. When you try to resolve a component from a child container, it looks at its own components to fulfil dependencies and if it doesn't find it, it asks the parent container if it can fulfil the dependency. This sounds like just the solution I needed. I can load all of my core components into the parent container, then load any custom components into a child container. One glaring flaw though. Lets say I have component A that has a dependency on component B. I have a core implementation of both components in my parent container. I have a custom implementation of component B in my child container. I attempt to resolve component A from the child container. It is not present so it is retrieved from the parent container. When resolving the dependency of component B, the parent uses the core implementation, not the custom implementation in the child container. I considered this a bug in the dependency resolution code and you can read about the ensuing discussion on the Castle mailing list. This issue was also reported by Rinat Adbullin a few months back and prompted him to choose another container implementation. I submitted a patch for my implementation but as far as I know it has not been applied. I've heard Hammett say that child containers are the devil (my words, not his) I believe because they can introduce difficult to diagnose bugs and make dependency resolution more complicated. For my problem they have provided an elegant solution.

To bring this implementation into MonoRail was simply a matter of crafting a custom HttpApplication that implements IContainerAccessor, and returning the appropriate child container based on the host header of the current request. I have the base container that contains all of the core components. I create a child container with the base as its parent for each client and load the appropriate components. MonoRail can be configured to use Windsor to resolve all of its internal components (including your controllers). MonoRail calls IContainerAccessor.Container to obtain the container to use for its resolution. By providing the appropriate child container to this call, I can ensure that any custom components for the particular client are used in place of the core components. By using the dependency resolution patch discussed above, I ensure that any core component dependencies are properly resolved against any existing customized components in the child container (code sample below).

To sweeten the deal, child containers are configured using a simple text file that can be modified at runtime to turn individual custom components on or off on a per client basis, without restarting the application. More on that in my future post on managing configuration.

namespace My.Application
{
  public class CustomHttpApplication : HttpApplication, IContainerAccessor
  {
    private static IWindsorContainer _baseContainer;

    private static readonly Hashtable _configToContainer = new Hashtable();

    protected virtual void Application_Start(object sender, EventArgs e)
    {
      _baseContainer = new CustomContainer();
    }

    public IWindsorContainer Container
    {
      get { return GetContainer(); }
    }

    protected virtual IWindsorContainer GetContainer()
    {
      string clientId = ClientIdProvider.Get();

      if (string.IsNullOrEmpty(clientId))
      {
        return _baseContainer;
      }

      ClientConfiguration clientConfig = ClientConfigurationManager.GetByClientId(clientId);

      IWindsorContainer clientContainer = null;

      if (!_configToContainer.ContainsKey(clientConfig.Path))
      {
        clientContainer = new CustomContainer(clientConfig, clientId, _baseContainer);
        _configToContainer.Add(clientConfig.Path, clientContainer);
      }
      else
      {
        clientContainer = (IWindsorContainer)_configToContainer[clientConfig.Path];
      }

      return clientContainer;
    }
  }
}