Simple scenario: OWSTIMER creates a new
SPListItem, populates it and calls .
Update(). It then fires an HTTP request over to
w3wp.exe (front-end app-pool) to invalidate an in-memory cache held there. Intermittently, we note that, though the HTTP request is fired after the .
Update() call, the new record is sometimes not found (yet) when
w3wp.exe queries the same data.
- This happens only intermittently, when the WRITE (by OWSTIMER) happens immediately before the READ (by
- The data is always eventually persisted, subsequent refreshes of
w3wp.exe(even seconds later) always include the new item
Disposeis not called on the parent
SPWeb/SPSitebefore the READ by
Is it possible that
SPListItem.Update() is not entirely synchronous (down to db commit) and that there is a write-delay or transaction isolation at the
SPWeb/SPSite levels? Even if the data is committed synchronously, it seems it's not made available to other processes (other SPSite instances) until the request that wrote the data completes or properly disposes.
Update() is happening inside of the
EmailReceived(SPList list, Microsoft.SharePoint.Utilities.SPEmailMessage emailMessage, string receiverData) event of an
SPEmailEventReceiver, hence why the parent SPWeb/SPSite aren't disposed. If there is indeed transaction isolation at play here, we could change the code to instantiate a new
SPSite/SPWeb for the WRITE to guarantee that these opjects are disposed before attempting to flush out the cache in