Understanding Unity Lifetime Managers

I absolutely love inversion of control, it is a best practice that I encourage developers to use in every project that they work on. However, like any great tool, dependency injection can cause serious problems if you do not fully understand it; lifetime management in particular.

As a developer you need to be cognisant of how many instances the container is constructing of your classes. You need to know when singleton is going to consume a transient or non thread safe resource. If you are not careful you can leak memory, share unsafe resources, or just make your garbage collector thrash.

Here is a series of examples regarding how to use lifetime managers in my favorite dependency injection container, Microsoft Unity.

1. ResolveType
2. Default Lifetime Manager
3. TransientLifetimeManager
4. RegisterInstance
5. ContainerControlledLifetimeManager
6. ExternallyControlledLifetimeManager
7. ContainerControlledLifetimeManager with Multiple Keys
8. RegisterType for Multiple Interfaces
9. ContainerControlledLifetimeManager with Multiple Interfaces
10. TransientLifetimeManager with Multiple Interfaces
11. RegisterInstance Multiple Times
12. RegisterInstance Multiple Times with External Lifetime Manager

Injectable Dataflow Blocks

I really enjoy working with Dataflows, but I always want to resolve my blocks with dependency injection. Thus I have created some abstract wrapper classes around the sealed ActionBlock and TransformBlock classes. This way your can put my logic into the superclass and inject it's dependencies via constructor injection. Additionally, the action method is public, making it even easier to test your code!

Update: I refactored to ditch the constructor parameters in favor of a new abstract BlockOptions.

Throttling Datafow and the Task Parallel Library

The Task Parallel Library is an amazingly powerful and versatile library. However, knowledge of how dataflow blocks process their data is vital to using them correctly. Trying to link source and target blocks to each other without fully understanding them is like throwing a live grenade into your app domain; at some point it will tear it down!

I recently experienced a bug where linking two blocks together without managing their Bounded Capacity caused them queue actions at an unsustainable rate, and eventually the dataflow literally eat all of the available memory on the server. This could have been easily avoided by throttling the source and target blocks.

How do you throttle your source block based on your target block?

Once linked together, a source block will produce messages as fast as it's target block can consume them. To prevent a source block from being too greedy, you want to restrict the bounded capacity for both it and it's consumer. Even then, you still need to understand that setting a bounded capacity could cause message producers to either block or fail to post.

...I'm sorry, but this subject is very complex, but I think code will explain these details best! Below are a detailed set of tests to take you through all the basic scenarios for throttling a dataflow:

ConcurrentDictionary.GetOrAdd and Thread Safety

.NET 4.0 added the awesome System.Collections.Concurrent namespace, which includes the very useful ConcurrentDictionary class. While the ConcurrentDictionary is thread safe, it can experience problems with adding values during high concurrency...

ConcurrentDictionary.GetOrAdd may invoke the valueFactory multiple times per key.

This behavior will only happens under high load, and even if the valueFactory does get invoked multiple times the dictionary entry will only ever be set once. Normally this is not much of a problem. However, if you are using this Dictionary to store large or expensive objects (such as unmanaged resources or database connections), then the accidental instantiation of multiple of these could be a real problem for your application.

Don't worry, there is a very simple solution to avoid this problem: just create Lazy wrappers for your expensive objects. That way it will not matter how many times the valueFactory is called, because only one instance of the resource itself will ever actually be accessed and instantiated.

Generic Enum Attribute Caching

Attributes are wonderful for decorating your Enums with additional markup and meta data. However, looking up attributes via reflection is not always a fast operation in terms of performance. Additionally, no one likes typing that code over and over again.

Well not to worry, just use the following extension methods to help cache your Enum attribute look ups, and increase your application's performance! But how much faster is this? Good question...

Iterations	Average Elapsed Ticks		Difference
	No Cache	With Cache
2	1182.00	3934.00	4x Slower
10	20.10	7.10	3x Faster
100	13.07	1.37	10x Faster
1,000	13.27	1.40	10x Faster
10,000	13.56	1.45	10x Faster
100,000	13.02	1.33	10x Faster

XUnit.PhantomQ v.1.2 Released

Want to run client side QUnit tests from Visual Studio or your build server? Now it is easier than ever; just grab newly updated XUnit.PhantomQ v1.2 from NuGet!

XUnit.PhantomQ will allow you to execute your QUnit tests as XUnit tests. It supports both library and web projects, and features the ability to easily specify test files and their dependencies by real relative path from the root of your project.

XUnit.PhantomQ on NuGet
XUnit.PhantomQ Source on GitHub

Change Log for v1.2

My thanks to James M Greene and the other authors of the PhantomJS Runner; their work served as the model for this version's improved test result information.

• Significantly improved test result information and error details.
• Added console.log support.
• Added test timeout configuration support.
• Added QUnit module support.
• Added QUnit result details to QUnitTest.Context

jQuery Mobile: Touch Events Only

jQuery Mobile touch events are awesome.

In a recent project I did not need ALL of the features that the jQuery Mobile framework had to offer; I only needed the excellent touch events. While jQuery Mobile does not offer a custom feature build that includes only the touch system, it is actually quite easy to create your own build.

Just download the following files and include them in your project; but be sure to delete the define method wrapper (the first and last line of each file), as you do not need them with the complete jQuery build.

1. jquery.mobile.ns.js
2. jquery.mobile.vmouse.js
3. jquery.mobile.support.touch.js
4. touch.js

...that's it, you can now use only jQuery Mobiles touch events!