4
Vote

UpdatedConcurrencyException: FarmSettingStore Name=_pnpFarmConfig_ was updated by another user

description

Similar to what occurred at the end of issue 6889, I have been able to reproduce this problem. The complete text is:
 
08/18/2010 16:09:16.64 w3wp.exe (0x0FAC) 0x04DC SharePoint Foundation Topology 75bd High UpdatedConcurrencyException: The object FarmSettingStore Name=_pnpFarmConfig_ was updated by another user. Determine if these changes will conflict, resolve any differences, and reapply the second change. This error may also indicate a programming error caused by obtaining two copies of the same object in a single thread. Previous update information: User: AA\administrator Process:vssphost4 (5348) Machine:AASP2010DEV Time:August 18, 2010 03:14:23.0000 Current update information: User: AA\administrator Process:w3wp (4012) Machine:AASP2010DEV Time:August 18, 2010 04:09:16.5230 e4057d12-e469-4f5d-9d06-4886da9a7497
08/18/2010 16:09:16.64 w3wp.exe (0x0FAC) 0x04DC SharePoint Foundation Topology 8xqy High ConcurrencyException: Old Version : 21301 New Version : 21301 e4057d12-e469-4f5d-9d06-4886da9a7497
08/18/2010 16:09:16.73 w3wp.exe (0x0FAC) 0x04DC Patterns and Practices SharePoint Guidance 0000 High SPFarmPropertyBag: Concurrency update failure when updating Key: 'PnP.Config.Key.Microsoft.Practices.SharePoint.DiagnosticAreas' e4057d12-e469-4f5d-9d06-4886da9a7497
08/18/2010 16:09:16.73 w3wp.exe (0x0FAC) 0x04DC Patterns and Practices SharePoint Guidance 0000 High ConfigManager: Failure saving config to 'CurrentSPFarm' level, retry count: '0', key: 'Microsoft.Practices.SharePoint.DiagnosticAreas' e4057d12-e469-4f5d-9d06-4886da9a7497
 
I have been redeploying the same feature multiple times which registers the diagnostic areas. I've had a lot of problems with the DLL from the feature being locked by VS2010, IIS, the SharePoint timer service, and the SharePoint User Code service (why this is happening beats me). So I've been regularly recycling/restarting these components such that the latest version of the DLL will deploy correctly to the GAC. I also began using the Central Admin to deploy the solution package and feature instead of VS2010 to try and minimise this problem. There is a chance VS2010 might have been activating/deactivating the feature while I also was in Central Admin although I don't remember doing this.
 
I'm going to run the little app I wrote at the end of issue 6889 to delete the farm setting store so I can continue working. However I thought you might like to know this occurred.

comments

ckeyser wrote Aug 18, 2010 at 8:48 PM

This is a tricky issue we spent a lot of time on this time. The exception is thrown by SharePoint, so there isn't anything we can do to resolve that. It is caused by a race condition between sites, so we try to minimize that race condition. The way that we do this is by reading back the settings right before update, and then writing the settings back immediately. We also provide a read/write lock around the settings so that we avoid multiple threads on the same machine attempting to write back at the same time. This should prevent this issue from occurring as a result of a race between threads on a single WFE.

Are you writing to the store only from the feature receiver, or are you also writing to the store from the timer job? Since an SPPersistedObject is read back as a single blob, any writes to farm level configuration could cause this condition, not just updating the logger areas/categories.

arangas wrote Aug 19, 2010 at 3:20 AM

I write to the store to update the diagnostic categories on activation and deactivation only, as in the code attached to issue 6955. Apart from that I'm just getting instances of ILogger and logging.

wrote Dec 23, 2010 at 4:18 PM

wrote Dec 20, 2011 at 3:53 PM

wrote May 10, 2012 at 2:14 AM

rroman81 wrote May 10, 2012 at 2:15 AM

i am having a similar issue wiht the event receiver now. How can I delete the property bag from the web app?

wrote Feb 22, 2013 at 12:32 AM