Dedicated concurrency properties 

Entity Framework offers support for optimistic locking through the ability to mark the concurrency mode of properties as "fixed".

Within Entity Framework, you can use this feature in two ways:

1. Mark (almost) all properties as having "fixed" concurrency mode. This will ensure that all properties will have their original values included in the WHERE clause of the UPDATE statement.

2. Mark a dedicated property as having "fixed" concurrency mode. This property could for instance be version number, or a datetime of last change.

The second approach requires specific support from the persistence layer. Hereby I present a solution for automating the update of dedicated concurrency properties with Entity Framework.

Sample case

Step 1 : Defining dedicated concurrency properties

Let's take a sample case. In an invoicing application, I define a "LastChanged" property on each of my entities:

Within the properties of the LastChanged property, the Concurrency Mode is set to "Fixed": 

Now, on the one hand the Entity Framework API does not provide at runtime information as to which properties have fixed concurrency mode (at least, I couldn't find it). On the other hand, such information would not sufice: to update the value of the dedicated concurrency property we need additional information:

Is it a dedicated concurrency property ?

What is the type of the property ?

What algorithm to use to compute it's next value ?

To provide this additional information, I introduced an OptimisticConcurrencyAttribute. This attribute decorates the entity type, tells which property is the dedicated concurrency property (usually only one, but multiple are supported) and which class to use to compute it's next value. As the EDM Designer generates entity classes that are partial, we can easily create a new part to decorate the entity type without changing the code generated by the EDM designer (and jeopardizing a regeneration by the EDM designer). For instance, I can create the following partial class:

namespace CodeTuning.Sample.Invoicing
{
    [OptimisticConcurrency("LastChanged", typeof(LocalDateTimeConcurrencyResolver))]
    partial class Customer
    {
    }
}

The LocalDateTimeConcurrencyResolver here referenced is one of three ConcurrencyResolvers pre-implemented:

LocalDateTimeConcurrencyResolver : for use with local DateTime typed dedicated concurrency properties.

UniversalDateTimeConcurrencyResolver : for use with universal DateTime typed dedicated concurrency properties.

VersionNumberConcurrencyResolver : for use with Int64 typed dedicated concurrency properties.

You can easily provide your own concurrency resolver type by implementing the following interface:

public interface IConcurrencyResolver<T>
{
    T NextValue(T actualValue);
}

Step 2 : Extending the ObjectContext

The second step is to extend the ObjectContext with the functionality to update dedicated concurrency properties on modified entities.

This is the task of the OptimisticConcurrencyManager class. Simply create an instance of it, and attach it to the context that will perform the SaveAllChanges() operation. For instance:

using (var context = new InvoicingContext())
{
    // Attach an OptimisticConcurrencyManager on the context:
    new OptimisticConcurrencyManager(context);

    ...

    // Save changes:
    context.SaveAllChanges();
}

However, the backdraw of this is that you need to attach the concurrency manager each time you create a context. I prefer to extend the context itself to have a concurrency manager attached in the following way: create a part of the partial class that the EDM designer generated, and implement the OnContextCreated partial method to create and attach an OptimisticConcurrencyManager:

namespace CodeTuning.Sample.Invoicing
{
    partial class InvoicingContext
    {
        partial void OnContextCreated()
        {
            // Automatically attach an OptimisticConcurrencyManager on each new context:
            new OptimisticConcurrencyManager(this);
        }
    }
}

That's all there is to do. The OptimisticConcurrencyManager registers to the context's WhenSavingChanges event, then queries the ObjectStateManager of the context and updates the dedicated concurrency properties of all modified entities.

If the dedicated concurrency property was modified on the entity, or by a concurrent transaction on the database, an OptimisticConcurrencyException will be raised. Otherwise, the dedicated concurrency property is updated on the entity, then checked and saved on database.

The code

The framework to support automated concurrency property updating, consists of the following code:

The IConcurrencyResolver interface:

namespace CodeTuning.Data.Entity
{
    /// <summary>
    /// Concurrency Resolver definition.
    /// </summary>
    /// <typeparam name="T">Type of the optimistic concurrency property</typeparam>
    public interface IConcurrencyResolver<T>
    {
        /// <summary>
        /// Provide the next value of the optimistic locking field, given
        /// it's actual value.
        /// </summary>
        T NextValue(T actualValue);
    }
}

Default implementations of the IConcurrencyResolver interface:

using System;

namespace CodeTuning.Data.Entity
{
    /// <summary>
    /// A ConcurrencyResolver for DateTime? properties containing LocalDateTime
    /// of last change.
    /// </summary>
    public class LocalDateTimeConcurrencyResolver : IConcurrencyResolver<DateTime?>
    {
        DateTime? IConcurrencyResolver<DateTime?>.NextValue(DateTime? actualValue)
        {
            return DateTime.Now;
        }
    }

    /// <summary>
    /// A ConcurrencyResolver for DateTime? properties containing UniversalDateTime
    /// of last change.
    /// </summary>
    public class UniversalDateTimeConcurrencyResolver : IConcurrencyResolver<DateTime?>
    {
        DateTime? IConcurrencyResolver<DateTime?>.NextValue(DateTime? actualValue)
        {
            return DateTime.UtcNow;
        }
    }

    /// <summary>
    /// A ConcurrencyResolver for Int64 properties containing a sequence number
    /// of last change.
    /// </summary>
    public class VersionNumberConcurrencyResolver : IConcurrencyResolver<long>
    {
        long IConcurrencyResolver<long>.NextValue(long actualValue)
        {
            return actualValue++;
        }
    }
}

The OptimisticConcurrencyAttribute class:

using System;
using System.Data.Objects;
using System.Linq;
using System.Reflection;

namespace CodeTuning.Data.Entity
{
    /// <summary>
    /// Declares a property for optimistic concurrency.
    /// </summary>
    [AttributeUsage(AttributeTargets.Class)]
    public sealed class OptimisticConcurrencyAttribute : Attribute
    {
        private string propertyName;
        private Type concurrencyResolverType;
        private object concurrencyResolver;

        /// <summary>
        /// Declares the optimistic concurrency attribute and its resolvertype.
        /// </summary>
        public OptimisticConcurrencyAttribute(string propertyName, Type concurrencyResolverType)
        {
            this.propertyName = propertyName;
            this.concurrencyResolverType = concurrencyResolverType;
            this.concurrencyResolver = Activator.CreateInstance(concurrencyResolverType);
        }

        /// <summary>
        /// Name of the concurrency property.
        /// </summary>
        public string PropertyName
        {
            get { return this.propertyName; }
            set { this.propertyName = value; }
        }

        /// <summary>
        /// Concurrency property value resolver type.
        /// </summary>
        public Type ConcurrencyResolverType
        {
            get { return this.concurrencyResolverType; }
            set { this.concurrencyResolverType = value; }
        }

        /// <summary>
        /// Whether the optimistic concurrency property has changed on the given instance.
        /// </summary>
        public bool HasPropertyChanged(ObjectContext context, object instance)
        {
            return context.ObjectStateManager.GetObjectStateEntry(instance).GetModifiedProperties().Contains(this.propertyName);
        }

        /// <summary>
        /// Updates the concurrency property on the given instance.
        /// </summary>
        public void UpdateInstance(object instance)
        {
            // Retrieve the property instance:
            PropertyInfo property = instance.GetType().GetProperty(this.propertyName, BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
            if (property == null) throw new ArgumentException(String.Format("ConcurrencyAttribute's PropertyName \"{0}\" not found."));

            // Invoke the NextValue method on the concurrency resolver, given the actual property value:
            object actualValue = property.GetValue(instance, null);
            Type iftype = typeof(IConcurrencyResolver<>).MakeGenericType(property.PropertyType);
            object nextValue = this.concurrencyResolverType.GetInterfaceMap(iftype).TargetMethods[0].Invoke(this.concurrencyResolver, new object[1] { actualValue });
            
            // Assign NextValue:
            property.SetValue(instance, nextValue, null);
        }

        /// <summary>
        /// Retrieves the OptimisticConcurrencyAttributes decorating the given entity type.
        /// </summary>
        public static OptimisticConcurrencyAttribute[] GetConcurrencyAttributes(Type entityType)
        {
            return (OptimisticConcurrencyAttribute[])entityType.GetCustomAttributes(typeof(OptimisticConcurrencyAttribute), true);
        }
    }
}

And finally the OptimisticConcurrencyManager class:

using System;
using System.Data;
using System.Data.Objects;

namespace CodeTuning.Data.Entity
{
    /// <summary>
    /// An Entity Framework addition to manage optimistic
    /// concurrency using OptimisticConcurrencyAttributes.
    /// </summary>
    public class OptimisticConcurrencyManager : IDisposable
    {
        private ObjectContext context;

        /// <summary>
        /// Instantiates a new OptimisticConcurrencyManager for the
        /// given ObjectContext.
        /// </summary>
        public OptimisticConcurrencyManager(ObjectContext context)
        {
            this.context = context;
            this.context.SavingChanges += new EventHandler(WhenSavingChanges);
        }

        /// <summary>
        /// Disposes the OptimisticConcurrencyManager, releasing it
        /// from the ObjectContext.
        /// </summary>
        public void Dispose()
        {
            if (this.context != null)
            {
                this.context.SavingChanges -= new EventHandler(WhenSavingChanges);
                this.context = null;
            }
        }

        /// <summary>
        /// Triggered when the attached ObjectContext saves changes.
        /// Changes optimistic concurrency attribute values.
        /// </summary>
        void WhenSavingChanges(object sender, EventArgs e)
        {
            // Update the concurrency properties of modified entities:
            foreach (var item in this.context.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Modified))
            {
                object entity = item.Entity;
                foreach (var attr in OptimisticConcurrencyAttribute.GetConcurrencyAttributes(entity.GetType()))
                {
                    // Verify the property was not yet updated, which could
                    // indicate an optimistic concurrency violation:
                    if (attr.HasPropertyChanged(this.context, entity))
                        throw new OptimisticConcurrencyException(String.Format("Concurrency property {0}.{1} contains invalid update.", entity.GetType(), attr.PropertyName));

                    attr.UpdateInstance(entity);
                }
            }
        }
    }
}

The issue

One of the very nice things of Entity Framework, but mainly a feature of .NET 3.5, is the ability to express a query in a syntax that combines SQL with C#/VB.NET: Linq. Not only does Linq to Entities provide a manner to express queries on the level of ‘conceptual’ entities, it also offers the ability of compile-time validation, which is a feature not to be under-estimated !

Take for instance the following Linq to Entities query:

var query = from p
    in context.ProductSet
    where p.SalePrice > 1000
    select p;

However, Entity Framework lacks compile safety when it comes to include related objects in the query. The Include operation to be used expects a string argument containing a path of properties to include in the query results, as in:

var query = from p
    in context.ProductSet
       .Include("PriceHistory")
       .Include("Supplier.Address")
    where p.SalePrice > 1000
    select p;

This query, which is supposed to return all products priced over 1000 including their price history, supplier and their address, does compile without compile time check of the included property paths. However, I might have modelled a product as to have several suppliers and renamed the property to it’s plural form ‘Suppliers’.

I found this to be an issue I wanted to solve...

The solution

.NET 3.5 has some very interesting features of which lambda expressions allow for compile time checking of expressions without the requirement to execute them, while extension methods allow us to add or overload methods on classes not under our control.

Combining both techniques, it is possible to offer an alternative Include method which uses a lambda expression as property path. With it, I can rewrite the above query in:

var query = from p
    in context.ProductSet
       .Include(p => p.PriceHistory)
       .Include(p => p.Supplier.Address)
    where p.SalePrice > 1000
    select p;

Would I refactor my entity model to support multiple suppliers per product, then this query would result in a compile error. I could then rewrite the query as follows:

var query = from p
    in context.ProductSet
       .Include(p => p.PriceHistory)
       .Include(p => p.Suppliers.First().Address)
    where p.SalePrice > 1000
    select p;

Notice that, as Suppliers has become a collection, I can not simply dereference Address of it. I can only dereference Address on individual items of the suppliers collection. Here I chose to dereference Address on the first item of the collection. In reality, this lambda expression is merely used to produce the property path “Suppliers.Address”, which will eager load the addresses of all suppliers.

The code

The code consists of a ObjectQuery<T> extension method which receives an Expression as argument:

using System;
using System.Collections.Generic;
using System.Data.Objects;
using System.Linq.Expressions;
using System.Reflection;
using System.Text;

namespace CodeTuning.Data.Entity
{
    /// <summary>
    /// Extension methods on ObjectQuery.
    /// </summary>
    public static class ObjectQueryExtension
    {
        /// <summary>
        /// Specifies the related objects to include in the query results using
        /// a lambda expression mentioning the path members.
        /// </summary>
        /// <returns>A new System.Data.Objects.ObjectQuery<T> with the defined query path.</returns>
        public static ObjectQuery<T> Include<T>(this ObjectQuery<T> query, Expression<Func<T, object>> path)
        {
            // Retrieve member path:
            List<PropertyInfo> members = new List<PropertyInfo>();
            EntityFrameworkHelper.CollectRelationalMembers(path, members);

            // Build string path:
            StringBuilder sb = new StringBuilder();
            string separator = "";
            foreach (MemberInfo member in members)
            {
                sb.Append(separator);
                sb.Append(member.Name);
                separator = ".";
            }

            // Apply Include:
            return query.Include(sb.ToString());
        }
    }
}

The core functionality of 'parsing' the lambda expression is isolated in a separate EntityFrameworkHelper class. I've done this because I reused this parser code for another feature which will be subject of a leter post on this blog:

using System;
using System.Collections.Generic;
using System.Linq.Expressions;
using System.Reflection;

namespace CodeTuning.Data.Entity
{
    internal static class EntityFrameworkHelper
    {
        internal static void CollectRelationalMembers(Expression exp, IList<PropertyInfo> members)
        {
            if (exp.NodeType == ExpressionType.Lambda)
            {
                // At root, explore body:
                CollectRelationalMembers(((LambdaExpression)exp).Body, members);
            }
            else if (exp.NodeType == ExpressionType.MemberAccess)
            {
                MemberExpression mexp = (MemberExpression)exp;
                CollectRelationalMembers(mexp.Expression, members);
                members.Add((PropertyInfo)mexp.Member);
            }
            else if (exp.NodeType == ExpressionType.Call)
            {
                MethodCallExpression cexp = (MethodCallExpression)exp;

                if (cexp.Method.IsStatic == false)
                    throw new InvalidOperationException("Invalid type of expression.");

                foreach (var arg in cexp.Arguments)
                    CollectRelationalMembers(arg, members);
            }
            else if (exp.NodeType == ExpressionType.Parameter)
            {
                // Reached the toplevel:
                return;
            }
            else
            {
                throw new InvalidOperationException("Invalid type of expression.");
            }
        }
    }
}

You can download this code from the following link:
EF_LambdaInclude.zip (1.35 kb)

I recently started investigating Entity Framework version 1. As many others have preceded me, I will not discuss what I believe are important issues or design flaws of EF. In stead I will focus on how to solve some of the issues and how to make better use of EF, as I believe EF deserves our attention.

Although I am not always thrilled of the Visual Studio designers that generate a lot of cumbersome code that does not fit in my frameworks, I decided to stick to the EDM designer which provides a graphical representation of my entities, and generates code that, thanks to partial classes and partial methods, is extensible to some degree. The knowledge that Microsoft intends to allow customization of the code generation process in later versions gives me satisfaction.

Focussing on client-server applications, I prepared some posts about better responsibility distribution and coping with detached object graphs.

So, stay tuned !