November 2009 - Posts
WCF does not promise thread affinity. This means that WCF does not promise that the thread that started the service operation execution will be the one who will finish the execution. In case the operation waits on some wait handle (wait for IO or DB for example) the thread might return to the thread pool and when execution should resume another thread might do the work.
public class MyService : IContract
{
public static object wait_handle;
public int LongOperation()
{
Before();
LongWait(); //Threads might be switched here
After();
return 0;
}
}
This fact enhance WCF scalability might introduce interesting synchronization scenarios.
If the operation is synchronized using a monitor (Using statement) it means that a Sync_Handle is associated with the thread.
If the execution thread is switched (no thread affinity) the second thread does not have the sync handle and the code will wait. On the other hand the starting thread might be assigned to another WCF request (after it was sent back to the thread pool). This next request have the sync_handle, it would not wait and it might cause damage to synchronized resources.
public class MyService : IContract
{
public static object wait_handle;
public int LongOperation()
{
lock (wait_handle)
{
Before(); //Thread1 has the lock
LongWait(); //Threads might be switched here
After(); // Thread2 does not have the lock but
it runs.
return 0;
}
}
public int SecondOperation()
{
// If accidently Thread1 is allocated it has the
handle and would enter the lock.
lock (wait_handle)
{
DoWork();
}
return 0;
}
}
The solution is simple.
Whene there is no thread affinity do not use monitor and the using statement. Use Events (autoReasetEvent or ManualResetEvent). When WCF perform a thread switch the second thread can set the event and the synchronization will continue as planned.
One of the problems with WF 3.5 is the debugging experience.
One of my customers complained that he could not put a break point on an activity in a workflow that was dynamically loaded to the runtime.
I checked and found out that it is simply not supported.
It is impossible to break on a workflow when it is dynamically loaded unless the breakpoint is put in the workflow code.
The problem is that usually the workflow has no code. It is made of pre created activities. Only when code activity is used or handlers are registered to events there will be code to break on.
Let us all wait to WF 4.0
There was a lot of effort to make WCF interoperable with almost every web service technology out there… But what about native code?
How can native code call a WCF service? How can native code be exposed as a web service?
Well you could always wrap native code with managed code but this introduced too many introp calls which degrades performance. You could also program against TCP sockets but manually implementing WS* is a nightmare.
Windows 7 brings an answer: wssapi – Windows Web Service API.
with wssapi you can easily create a native proxy to a WCF service. You can also expose your native code using a native service and a native host and create a web service that looks and feels like a WCF service.
To learn more about in I strongly recommend watching the following videos.
- Native Web services Part1
- Native Web services Part 2
- Web Services in native code
wssapi will also support XP Server 2003 and Server 2008.
Enjoy
Windows Server "Dublin" is a collection of enhanced capabilities added to the Windows server platform which will expand and take Internet Information Services (IIS) to the next level. The end purpose of the improvements planned for the Windows Application Server is to permit developers to handle composite applications in a much simpler way than they can today.
Dublin will allow simple Yet powerful WF and WCF hosting.
Dublin includes a set of advanced logging and monitoring capabilities that will enable easy management of large sets of services and WF instances. A First look an Dublin can be found here.
The question is when?
So here is the timeframe that was released with the Dublin Technology Adoption Program (TAP).
Q3 2009 (Oct-Dec)
Beta 1 release
Q1 2010 (Jan-Mar)
Beta 2 release
Q2 2010 (Apr-Jun)
RTM