Recursive locks in editor & background tasks since upgrade to umbraco 13

,

I’m suddenly receiving “Recursive Locks” error since my solution upgraded to Umbraco 13.
This was not the case in Umbraco 10.

I have several background tasks running, while content editors work in Umbraco tree as well.

I have already tried to add scopes in my recurring tasks but it doesn’t seem to help.

Anyone encountered this before?

Thanks!

1 Like

I also have this issue.

I update one content node per background task with Hangfire.

When I first got this error I started searching and I found an article about distributed locks.

I wrapped my save operation in this scope, but I still get this exception:

My code looks something like:

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();
    }
}

Try removing this line:

contentService.SaveAndPublish() calls this internally.

Now I get this exception:

Transaction (Process ID 65) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Or the same one as before…

I’d really like to come to the bottom of this issue…

Should I create a custom semaphore for that operation?

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.

Any luck so far @gregor-tusar-sowa @Neirijnck?

No, we couldn’t fix this yet.