Patrick’s Bytes

During my ILL Lab tag team with Ervin about Linq to SQL, quite a number of attendees asked us about Linq to SQL performance compared to ADO.NET SQLConnection. I couldn’t provide too much information but I remember Rico Mariani’s blog on Linq performance so I asked them to search for it. Search no more, here is the direct link, 5 parts of them about detail study on Linq to SQL performance.

There seem to be quite a lot of questions in forums and blog post about inability of have LINQ to SQL object in a Workflow Foundation’s Activity execution. Most of the time, you will end up getting a error message as below

Type ‘System.Data.Linq.ChangeTracker+StandardChangeTracker’ in Assembly ‘System.Data.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ is not marked as serializable.

After I did some research and found out about serialization method in LINQ to SQL here:

http://msdn.microsoft.com/en-us/library/bb386929.aspx

Code generation in LINQ to SQL supports DataContractSerializer serialization. It does not support XmlObjectSerializer or BinaryFormatter. For more information, see Serialization (LINQ to SQL).

However for Workflow Foundation, it is using BinaryFormatter to serialize objects into persistent layer (refer the MSDN document here)

When the workflow runtime encounters a persistence point during workflow instance execution, it calls the persistence service to do the work. The persistence service will then serialize the workflow state into a stream using BinaryFormatter serialization, optionally compress it, and save it into a durable store.

As such there is a crash here which renders LINQ to SQL entities can’t be used in Workflow Foundation. Fortunately Serena Yeoh found a solution and put it into her project at Layer Sample. You can found out more at this forum thread. Basically her code will take LINQ to SQL objects, clone it and serialize it using DataContractSerializer first before committing changes. Then after that it will return the cloned copy.