Service Deadlocks?

I recently read a post by Nicholas Allen about "avoiding OneWay deadlocks" (using Indigo, ah, Windows Communication Foundation). The article explains some of the technical issues behind OneWay messages. What's more interesting, however, is the issue of deadlock and services.

If you architect/design a SOA solution where you get deadlocks between services, well, you shouldn't be designing SOA solutions in the first place. Alternatively , if you are just using "web-services" technology to implement plain old RPC, while thinking web services will absolve you from your RPC pains (such as worrying about deadlocks), then it serves you right.

In my eyes, one of THE anti-patterns for SOA is extending transactions over a call outside the service. For one, you can't assume an external service will be willing to participate in your transaction. More importantly, you cannot afford to do so. The service boundary is a trust boundary. services on the outside do not care about you. performing a distributed transaction from one service to another is giving up on service autonomy.

Even if you don't try to have a remote service participate in your transaction and just want to wait for the other service to return within an internal transaction you still have bad design. This is opening your service to deadlocks as your service now holds a resource locked for the duration of the call, which, mind you, is a remote one over the wire one. (Remember the Fallacies of Distributed Computing.)

A better approach is have the data cached locally when your service needs it. you can do that either by actively going and fetching data by implementing a patterns I call "Active Service" (a service with an active thread that can talk to other services on a scheduled basis) or have other services publish their state continuously (a pattern I call "Inversion of Communications"). This way when the service needs external data it just checks out the local cache which makes the service more autonomous, robust and "deadlock" free.

Posted by Arnon Rotem-Gal-Oz at 07:25 AM  Permalink