Nested transactional scopes just because of non serializable code

It's good to avoid having non serializable code in an orchestration. I give you an example: Let's say you have non serializable code in an expression shape which need not to be executed transactional. The pitty is, that you have to put an atomic transaction scope around it. The reason is that BizTalk only allows non serializable code in this kind of scope. In addition to that, you need another long running transaction scope around the first one, if you want to do some exception handling. BizTalk does not allow you to add an exception handler to an atomic transaction scope. So, there is a lot of overhead just because of the non serializable code in the beginning. If performance is a critical factor, here is potential. The best way would be to make the code serializable or to outsource it to a custom .NET class. For the second option it is important to make the methods static which are called by the orchestration. The benefit would be that you only need one non transactional scope in the given example. (See Biztalk : Atomic Transaction for Exception handling and Atomic scope for Non Serializable code)