WCF Service Throttling settings for concurrency with SQL Transaction

I have a WCF service that has a complex operationcontract that has to executed atomically i.e. either the entire operation succeeds or fails. The WCF service is hosted on IIS server in an ASP .NET application. This operation has a sequence of SQL commands that execute in a transaction. During tests I found that with concurrent access by 4 - 5 users, atleast one user gets "Transaction Deadlock" error.

I then looked at the serviceThrottling settings which I had set to

<serviceThrottling  maxConcurrentCalls ="5" maxConcurrentInstances ="50" maxConcurrentSessions ="5" />

and changed it to

<serviceThrottling  maxConcurrentCalls ="1" maxConcurrentInstances ="1" maxConcurrentSessions ="1" />

I have turned off session since I don't need in the service contract. So I don't know whether maxConcurrentSessions will be having any effect at all

<ServiceContract([Namespace]:="http://www.8343kf393.com", SessionMode:=SessionMode.NotAllowed)>

This way I was queuing up the requests so that the request are processed serially instead of concurrently. While the transaction issue got away, the process time increased which was expected.

I was 开发者_Go百科wondering

1. Whether serviceThrottling is the only way to resolve this issue ?

2. How can I set serviceThrottling such that while the service will accept many requests at the same time but will process one at a time?

3. Is setting the InstanceContextMode=InstancePerContext.PerCall relevant here since the application is ASP .Net application which in itself is multithreaded ?

1. Well, i think your going about this the wrong way trying to solve a database deadlock with WCF throttling. you should try to understand why your database operations causes a deadlock, and try to avoid it (by using maybe locking hints.)
2. a singleton will do what you ask , but that isnt very scalable.
3. it is relevant but i think you get my drift , solve the deadlock in the database not in WCF.

if its SQL server that you are using , theres a great tool to analyze deadlocks (and a lot more) and its called the SQL Profiler. Also its a fairly well documented topic in the SQL Books Online

Your changes caused the WCF service to function as a singleton instance. That fixed your database concurrency issue but it only pushed the process blocking into the client.

I'd recommend using a different approach to remove the client blocking penalty. You should consider making this service, or at least extracting that operation into a new service that uses a netMsmqBinding (a good overview is here). This means the client will never be blocked and it guarantees delivery of the request to the service. The tradeoff is there can be no immediate response to the request, you'll need to add another operation to poll for completion status and to retrieve any expected results. It does require more work to spin up an MSMQ based service but the reliability is usually worth the effort.