Dirty read concept in Entity Framework using C#

Question

I am working on Web API using Entity Framework and C#. I need solution for dirty reads.

I have tried below method and also transaction method, I need solution for dirty reads.

Dirty reads or phantom reads is a phenomenon where a user is not updating the latest data.

Let's say user A has opened salesman web page

user B also opened the same salesman web page

A has loaded salesman ID 1001 and B also loaded 1001 A changed salesman name to X and saved.

But B is seeing old data and if B changes the salesman name to Y, A's changes will be overwritten. So we should prevent B from writing the changes to DB.

So I need solution based on the above concept.

using (var transaction = db.Database.BeginTransaction())
{
    try
    {
        db.SaveChanges();
        transaction.Commit();
    }
    catch (Exception excp)
    {
        throw excp;
    }
}

return Ok();

Below is the code that I have tried

using (var transaction = db.Database.BeginTransaction())
{
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }

    KSTU_COUNTER_MASTER kcm = new KSTU_COUNTER_MASTER();
    kcm.obj_id = Common.GetNewGUID();
    kcm.company_code = Common.CompanyCode;
    kcm.branch_code = Common.BranchCode;
    kcm.counter_code = c.CounterCode;
    kcm.counter_name = c.CounterName;
    kcm.Maincounter_code = c.MaincounterCode;
    kcm.obj_status = c.ObjectStatus;
    kcm.UpdateOn = Framework.Common.GetDateTime();
    kcm.UniqRowID = Guid.NewGuid();

    db.KSTU_COUNTER_MASTER.Add(kcm);

    try
    {
        db.SaveChanges();
        transaction.Commit();
    }
    catch (Exception excp)
    {
        throw excp;
    }
}

return Ok();

Answer 1

Let's say user A has opened salesman web page user B also opened the same salesman web page A has loaded salesman ID 1001 and B also loaded 1001 A changed salesman name to X and saved.

The comments are correct that this is a problem that requires client-side Optimistic Concurrency checks, not a database transaction. But I wanted to explain why that is.

You actually could use a transaction here, in SNAPSHOT, REPEATABLE READ, or SERIALIZABLE isolation level. A and B would both be able to open the same salesman page and peform the edits, but whichever one tried to save last would cause an error (This error might be a deadlock depending on the isolation level). But the write-over-write anomaly would be prevented.

However to make that work you would have to keep the database connection, and the transaction open from the time each user navigated to the "salesman web page" to the time the user saved the data. And in a web application, you have no information about or control over how long that is. In a client-server application you can sort of make this work, but in web apps this approach was almost universally abandoned in favor of client-side optimistic concurrency.