private void UpdateItem<T>(IPublishedContent? jobConfig)
{
using var scope = scopeProvider.CreateScope();
scope.WriteLock(Constants.Locks.ContentTree);
try
{
// get job configuration as IContent from IPuiblishedContent or create new one
IContent?jobConfigContentItem = contentService.GetById(jobConfig.Id);
// assign new value to config
jobConfigContentItem.SetValue("PropertyName"), "udi://.....");
contentService.SaveAndPublish(jobConfigContentItem);
}
finally
{
scope.Complete();
}
}
We are seeing the same issue in our 13.7.1 instance. We have an endpoint that creates and/or updates some nodes. If that is requested while an editor is busy (or it’s requested twice at the same time) it errors out with the ‘Recursive locks not allowed’ message. Adding an explicit core scope does not solve the issue, but seems to change the error message to either the deadlock error mentioned by @gregor-tusar-sowa, or a write lock timeout. The timeout makes sense and we can circumvent that with retries, but I’d like to avoid retries on the other errors if it’s a symptom of us doing something wrong.
Online there is also inconsistent information on when it’s needed to use explicit scopes when using the ContentService. For example: the docs don’t mention scopes, but this comment mentions to always use scopes in write operations.