Topics: General, Troubleshooting
Feb 3, 2015 at 3:19 AM
We are experiencing a problem with deadlocks. We have just migrated from Orchard 1.6 to Orchard 1.81 and we are wondering if this could be related. We will be doing further testing tomorrow to see if we can stress a 1.6 version of our site and generate the same deadlocks.

Logging in to the same account multiple times simultaneously generates the problem for us. Of course, this is a somewhat unnatural situation but we remain troubled because the deadlocks can block the entire operation of the site.

We have read earlier threads suggesting ideas such as:
<add key="Orchard:MaxConcurrentRequests" value="24" />
<add key="Orchard:MaxEnqueuedRequests" value="256" />


"Sébastien is suggesting switching to ReadUncommitted transaction isolation level. To do that, open TransactionManager.cs (in Orchard.Framework/Data) and in the Demand method, change ReadCommitted to ReadUncommitted. Which makes me wonder, Sébastien, why isn't this the default when using Sql Server?" - from Bertand at:

Our deadlock error message is very similar to the one at:

What experience do people have with this issue and what are currently considered best approaches for dealing with it?

thanks, Mike Cullina
Feb 3, 2015 at 6:46 AM
Err, those keys are a custom addition made by me for - it is not part of Orchard nor is it publicly available.

It is a big rewrite of the WarmupHttpModule.cs file

Switching to ReadUncommited (that we did) gave us some additional problems regarding cleaning the cache but could 'solve' your problem if you can deal with the 'new' problems it 'might' give:

By default (when using ReadUncommited) when you signal a signal to 'reset' a cache entry, it 'could' cache the prev value again if there was a request between clearing the cache entry (by signaling) and committing pending changes. Atleast, this was my observation.

We fixed (worked around) this by hacking the Signals service adding the ability to execute pending 'signals' AFTER the transaction has been committed.
Feb 3, 2015 at 10:10 AM
Thanks for the feedback AimOrchard. We are finding that we can resolve the issue with ReadUncommitted and now we are looking at how narrowly we can use it and we will definitely analyze and manage the side effects if we go this way. We'll report back to the group on our findings.