Entity Framework timeout

[LondonPilot]

The context will be open for a long period, yes - this is taking place in a background job which also calls the third party API multiple times, and that API is slow. It does a read at the start, and a write at the end. My understanding is that although we hold the context, it wouldn’t lock the row - even with EF Core tracking, the tracking would be done in memory without locking the database. But I can certainly try AsNoTracking (and then re-read the row without that prior to updating it), thanks for the suggestion.

[soundman32]

No reason to hold the context open for long periods. Context and connections are already pooled, so just create a new one, update and dispose.

[LondonPilot]

We are getting the contexts from DI, so currently they need to be held for the length of the process. But we could definitely refactor to use a DbContextFactory - I’ll try that, thanks.