concurrency

After SaveChangesAsync, EF Core 11 copies store-generated keys, defaults, computed columns and concurrency tokens back into your entities, fixes up foreign keys and navigations, and resets every entry to Unchanged. Here is exactly what gets written, when, what the SQL looks like, and four cases where the value on your entity is not what is in the database.

Use Lazy<T> by default: it runs the factory once, caches exceptions, and its reads are too cheap to measure after initialization. Use LazyInitializer.EnsureInitialized when you lazily fill many fields or array slots and cannot afford an extra object per value. Hand-written double-checked locking is almost never worth it on .NET 10.

Use await Task.Delay for any timed wait in async code, Thread.Sleep only on a dedicated thread you own, and SpinWait only for sub-microsecond waits inside lock-free code. To wait for a condition, use a signal (ManualResetEventSlim, SemaphoreSlim, TaskCompletionSource) instead of any of the three. Measured on .NET 10.0.10.

Volatile.Read is an acquire load of one location. Volatile.ReadBarrier, new in .NET 10, is a fence that gives every earlier read acquire semantics. Use Volatile.Read for flags and published references, and ReadBarrier when you need a batch of plain or non-atomic reads to complete before the next memory access, as in a seqlock.

Loading an entity, calling List.Add, and saving rewrites the whole jsonb document and silently loses concurrent appends. Push the append into one UPDATE with the jsonb || operator, either through ExecuteSqlAsync or a mapped function inside ExecuteUpdateAsync, and make it idempotent with a @> guard.

The existence check in your handler is not the guard you think it is. Put a unique index on the inbox table, write the marker in the same SaveChanges as the business change, and let the database pick the winner. Plus the ExecuteUpdate trap that quietly undoes all of it.

EF Core 11 still has no lock API. Here is how to take a real row lock with FromSql: WITH (UPDLOCK, ROWLOCK) on SQL Server, FOR UPDATE on PostgreSQL, the subquery trap that silently widens the lock, NOWAIT and SKIP LOCKED, deadlock retries, and what to do when the row does not exist yet.

The check-then-insert in your handler is not atomic. Catch PostgresException with SqlState 23505, or collapse the whole thing into one INSERT ... ON CONFLICT statement. EnableRetryOnFailure will not help.

A thread shares memory with every other thread in the process. A Dart isolate does not: it owns its heap, runs one event loop, and talks to other isolates only by messages. Here is what that means at the VM level, where isolate groups blur the line, and how it plays out in Flutter, FFI, and on the web.

Add a rowversion concurrency token in EF Core 11: the [Timestamp] and IsRowVersion setup, the SQL EF actually emits, catching DbUpdateConcurrencyException, store-wins vs client-wins vs merge, disconnected APIs with ETags, and the five traps that silently disable the whole thing.