SPReaderWriteLock Issues
Recently I’ve been looking at the ULS in a bit more detail. In short I’ve been focussing on anything in the following categories:
- Critical
- Unexpected
- Monitorable
- Warning
I wrote a PowerShell script that monitors the ULS logs and sends me emails when anything occurs within the above categories.
One of the errors that I have found quite often is the SPReaderWriterLock. What do these errors mean?
Something is trying to read or write while something else is updating the same item. In other words the item has been locked.
example 1
OWSTIMER Service generates the following error twice :
SPReaderWriterLock named [SPInitializeOnceLock] held for 3104 milliseconds. Call stack: at Microsoft.SharePoint.Utilities.SPReaderWriterLock.SPReaderWriterLockScope.Dispose() at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.get_ReferencedAssemblies() at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.SubCompiler.AddReferenceableAssemblies(WorkflowCompilerParameters theParameters) at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.SubCompiler.DoCompile(WorkflowCompilerParameters parameters, String xomlSource, String assemblyName, CompilationPacket& packet, DirectoryInfo& tempDir)
Explanation: In my case two Nintex workflows try to update the same item.
example 2
miiserver returns the following 2 messages:
SPReaderWriterLock named [Process Context Lock] held for 1357 milliseconds. Call stack: at Microsoft.SharePoint.Utilities.SPReaderWriterLock.SPReaderWriterLockScope.Dispose() at Microsoft.SharePoint.SPProcessContext.Get[T]() at Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Farm() at Microsoft.SharePoint.Administration.SPConfigurationDatabase.SPFileSystemCacheWatcher.OnChanged(Object source, FileSystemEventArgs e) at System.IO.FileSystemWatcher.CompletionStatusChanged(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* overlappedPointer) at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
SPReaderWriterLock named [Process Context Lock] waited 109 milliseconds to acquire lock. Call stack: (enable Verbose for stack trace)
Explanation: The SharePoint config database is being updated at the same time
example 3
PowerShell generates the following twice in my logs
SPReaderWriterLock named [XmlDocumentCache_Items] waited 141 milliseconds to acquire lock. Call stack: (enable Verbose for stack trace)
Solutions
There is a theme here. Whenever this error (Unexpected messages really shoud not appear in your SharePoint logs) occurs there are always two messages. They are always fairly similar or the same.
So how do we avoid this. Better coding? Perhaps.
It can be quite tricky in languages like PowerShell or Nintex to get enough control over item level locks. However there is something you can do.
- Always make sure that only one automated process updates items
- No ‘spaghetti workflows’ where workflows trigger other workflows. It is better to create a single workflow.
- Keep all logic in a single place. a mix of PowerShell scripts, Event handlers and workflows is not a good idea.
Example 4
And then I find a 4th example:
SPReaderWriterLock named [SPObjectCachedItem] waited 140 milliseconds to acquire lock. Call stack: (enable Verbose for stack trace)
Just a single entry referring to the Object Cache…
Can example 1 cause a couple of Nintex Workflows to enter “Errored” state? Right after SPReaderWriterLock error in ULS I got this error:
Nintex.Workflow.NWException: HandleFaultError. —> System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.Workflow.SPWinOEWSSService.GetWebForWorkflow(SPWorkflow wf, SPWorkflowUserContext runAsUser)
And some Workflows entered “Errored” state.
Hi Georgi,
That is quite likely that you would get errors like that. You would probably have to go through each workflow and see in which step they failed. Multiple workflows that update/read the same items are always risky. Personally, I would recommend State Machine workflows instead of multiple small workflows.
You might want to have a look at:
Developing Error Free Workflows in Nintex
and
Developing Top Down Code Free Workflows Using SharePoint 2013 and Nintex Workflow
Thank you for the reply.
We are digging further into the issue and involved Nintex Support. Will let you know when we figure it out.
You’re advice that it’s better to create single workflows is completely subjective.
Creating multiple workflows is good practice in certain circumstances.
I think better advice would be to think through the logic of your workflow/s and ensure the workflow actions do not interrupt or interfere with each other.
Hi darkpenguin350, Of course it is possible to create multiple workflows. In general for each flow of work I would create a single workflow.
So I would always use State Machines to bundle all my smaller parts of the process. This way I keep a single audit log of the process making the process easier to understand.
If you decided to create multiple workflows where one workflow could start another workflow then it is a lot harder to make sure things don’t interfere with each other. More importantly when workflows do interfere it is very difficult if not impossible to debug what happened first.