Enable ASP.Net Core Session Locking?

Question

According to the ASP.Net Core docs, the behaviour of the session state has changed in that it is now non-locking:

Session state is non-locking. If two requests simultaneously attempt to modify the contents of a session, the last request overrides the first. Session is implemented as a coherent session, which means that all the contents are stored together. When two requests seek to modify different session values, the last request may override session changes made by the first.

My understanding is that this is different to the behaviour of the session in the .Net Framework, where the user's session was locked per request so that whenever you read from/wrote to it, you weren't overwriting another request's data or reading stale data, for that user.

My question(s):

1. Is there a way to re-enable this per-request locking of the user's session in .Net Core?

2. If not, is there a reliable way to use the session to prevent duplicate submission of data for a given user? To give a specific example, we have a payment process that involves the user returning from an externally hosted ThreeDSecure (3DS) iFrame (payment card security process). We are noticing that sometimes (somehow) the user is submitting the form within the iFrame multiple times, which we have no control over. As a result this triggers multiple callbacks to our application. In our previous .Net Framework app, we used the session to indicate if a payment was in progress. If this flag was set in the session and you hit the 3DS callback again, the app would stop you proceeding. However, now it seems that because the session isn't locked, when these near simultaneous, duplicate callbacks occur, thread 'A' sets 'payment in progress = true' but thread 'B' doesn't see that in time, it's snapshot of the session is still seeing 'payment in progress = false' and the callback logic is processed twice.

What are some good approaches to handling simultaneous requests accessing the same session, now that the way the session works has changed?

Answer 1

The problem that you have faced with is called Race Condition (stackoverflow, wiki). To cut-through, you'd like to get exclusive access to the session state, you can achieve that in several ways and they highly depend on your architecture.

In-process synchronization

If you have a single machine with a single process handling all requests (for example you use a self-hosted server, Kestrel), you may use lock. Just do it correctly and not how @TMG suggested.

Here is an implementation reference:

1. Use single global object to lock all threads:

  private static object s_locker = new object();

  public bool Process(string transaction) {
      lock (s_locker) {
        if(!HttpContext.Session.TryGetValue("TransactionId", out _)) {
           ... handle transaction
        }
      }
  }

Pros: a simple solution Cons: all requests from all users will wait on this lock

2. use per-session lock object. Idea is similar, but instead of a single object you just use a dictionary:

    internal class LockTracker : IDisposable
    {
        private static Dictionary<string, LockTracker> _locks = new Dictionary<string, LockTracker>();
        private int _activeUses = 0;
        private readonly string _id;

        private LockTracker(string id) => _id = id;

        public static LockTracker Get(string id)
        {
            lock(_locks)
            {
                if(!_locks.ContainsKey(id))
                    _locks.Add(id, new LockTracker(id));
                var res = _locks[id];
                res._activeUses += 1;
                return res;
            }
        }

        void IDisposable.Dispose()
        {
            lock(_locks)
            {
                _activeUses--;
                if(_activeUses == 0)
                    _locks.Remove(_id);
            }
        }
    }


public bool Process(string transaction)
{
    var session = HttpContext.Session;
    var locker = LockTracker.Get(session.Id);
    using(locker) // remove object after execution if no other sessions use it
    lock (locker) // synchronize threads on session specific object
    {
        // check if current session has already transaction in progress
        var transactionInProgress = session.TryGetValue("TransactionId", out _);
        if (!transactionInProgress)
        {
            // if there is no transaction, set and handle it
            HttpContext.Session.Set("TransactionId", System.Text.Encoding.UTF8.GetBytes(transaction));
            HttpContext.Session.Set("StartTransaction", BitConverter.GetBytes(DateTimeOffset.UtcNow.ToUnixTimeSeconds()));
            // handle transaction here
        }
        // return whatever you need, here is just a boolean.
        return transactionInProgress;
    }
}

Pros: manages concurrency on the session level Cons: more complex solution

Remember that lock-based option will work only when the same process on the webserver handling all user's requests - lock is intra-process synchronization mechanism! Depending on what you use as a persistent layer for sessions (like NCache or Redis), this option might be the most performant though.

Cross-process synchronization

If there are several processes on the machine (for example you have IIS and apppool is configured to run multiple worker processes), then you need to use kernel-level synchronization primitive, like Mutex.

Cross-machine synchronization

If you have a load balancer (LB) in front of your webfarm so that any of N machines can handle user's request, then getting exclusive access is not so trivial.

One option here is to simplify the problem by enabling the 'sticky session' option in your LB so that all requests from the same user (session) will be routed to the same machine. In this case, you are fine to use any cross-process or in-process synchronization option (depends on what you have running there).

Another option is to externalize synchronization, for example, move it to the transactional DB, something similar to what @HoomanBahreini suggested. Beware that you need to be very cautious on handling failure scenarios: you may mark your session as in progress and then your webserver which handled it crashed leaving it locked in DB.

Important

In all of these options you must ensure that you obtain lock before reading the state and hold it until you update the state.

Please clarify what option is the closest to your case and I can provide more technical details.

Answer 2

Session is designed to store temporary user data among multiple requests, a good example is login-state... without session you would have to login to stackoverflow.com every time you open a new question... but the website remembers you, because your send them your session state inside a cookie. According to Microsoft:

The session data is backed by a cache and considered ephemeral data. The site should continue to function without the session data. Critical application data should be stored in the user database and cached in session only as a performance optimization.

It is quite simple to implement a locking mechanism to solve your mutex issue, however the session itself is not a reliable storage and you may loose its content at any time.

How to identify duplicate payments?

The problem is you are getting multiple payment requests and you want to discard the duplicate ones... what's your definition of a duplicate payment?

Your current solution discard the second payment while a first one is in progress... let's say your payment takes 2 seconds to complete... what will happen if you receive the duplicate payment after 3 seconds?

Every reliable payment system includes a unique PaymentId in their request... what you need to do is to mark this PaymentId as processed in your DB. This way you won't process the same payment twice, no matter when the duplicate request arrives.

You can use a Unique Constraint on PaymentId to prevent duplicate payments:

public bool ProcessPayment(Payment payment) {
    bool res = InsertIntoDb(payment);
    if (res == false) {
        return false; // <-- insert has failed because PaymentId is not unique
    }        
    
    Process(payment);
    return true;
}

Same example using lock:

public class SafePayment {
    private static readonly Object lockObject = new Object();

    public bool ProcessPayment(Payment payment) {
        lock (lockObject) {
            var duplicatePayment = ReadFromDb(payment.Id);
            if (duplicatePayment != null) {
                return false; // <-- duplicate 
            }
            
            Process(payment);
            WriteToDb(payment);
            return true;
        }
    }
}