Charlie Mott

  Home  |   Contact  |   Syndication    |   Login
  20 Posts | 0 Stories | 17 Comments | 0 Trackbacks


View Charlie Mott's profile on LinkedIn


Post Categories

Tuesday, February 16, 2010 #

Article Source:

There are various blog articles that give sample .NET code that can be used to validate a message against a schema from a BizTalk orchestration.  These include: msdn,,, and Sujan Turlapaty.

Many of these blogs have subsequent comments about problems.  Under high loads, I too began to see these classes return “false positives” in my test environment.  (i.e. An XmlSchemaValidationException is being thrown against valid messages. When the messages are re-submitted individually, they pass validation without problems.)

Doing a bit more research into this, I found this Microsoft XML Team's WebLog article about the lack of thread safety of the XmlSchema and XmlSchemaSet classes. 

This article also states that "for some reason, this "breaks" more on 64-bit machines, but it's unsafe on all architectures".  This would explain why I only began to see the problem when we started testing on 64-bit servers.  I never experienced the problems on my 32-bit development or build machines.  Nor could I break the code in a unit test using Roy Osherove's ThreadTester.  So, another lesson learnt - always develop on the same OS type as the target machines.

To circumvent this problem, I am now calling a validation pipeline from the orchestrations. (I am using a pipeline with Saravana Kumar's Extended XML Validation Pipeline Component so that exceptions report all the validation errors, not just the first). This is working well. However, it does mean that I have had to set the orchestrations to run as long-running transactions.

Update (19/02/2010): Both the out-of-the-box validation pipeline component and Saravana Kumar's Extended XML Validation Pipeline Component, use the deprecated XmlSchemaCollection class. This class is more thread safe than the replacement XmlSchemaSet class.  As such, rather than the above solution of calling a pipeline from an orchestration, another solution would be to modify the validation method to use the XmlSchemaCollection instead of the XmlSchemaSet class.