Practical ASP.NET

Never Lock Records in Web Applications! Never! That Means You!

Seriously, don't. Here are two reasons why record locking is simply a bad idea.

Here's a negative column for you, all about something you should never, never do in an ASP.NET application: Lock records when retrieving records in order to resolve data contention.

My clients often worry about data contention. The scenario they have in mind goes something like this:

  • Sue retrieves a Customer record at 9:00 and makes a change to the CustomerName field.
  • Lou retrieves the same record at 9:01 and changes the CustomerCredit field.
  • Sue clicks her submit button and updates the record at 9:02.
  • Lou clicks his submit button and updates the record at 9:03.

At this point, the ASP.NET DataSources create a problem by updating every field in the record. Because of that default behavior, Lou's update at 9:03 overwrites Sue's change to the CustomerName field saved at 9:02 by using the original data Lou retrieved at 9:01. This is bad. My clients usually suggest that we solve the problem by "locking records when someone retrieves them." This is worse.

It's not an accident that ADO.NET doesn't include any native commands to support record locking: You don't want to lock records in your database, especially in an ASP.NET application.

Record Locking Is Evil: Reason No. 1
The first reason that you don't want to lock records is because it generates extra work for you. Start by thinking about the process for when data is retrieved in an ASP.NET application: The user's request hits your site, your code retrieves the requested record, you embed its data into the WebForm and then send the page down to the user.

Now what happens? The user looks at the screen deciding what to do and the record remains locked. The user may, eventually, decide to do nothing and just hit the submit button -- your record locking was unnecessary and, in addition, you must add code to your page to release the lock.

Or the user may select a choice from one of your menus and navigate to another page on your site. Since the current page's code isn't called when a menu choice (or any hyperlink) is selected, you'll have to set up some system to check for locked records on previous pages and release them.

Alternatively, the user may shut down their browser or wander off to some other site. In either of these cases, no code on your site will execute and the record will stay locked forever. To handle this, you'll need some system that sweeps through your database looking for records that have been locked for "too long" and release them.

So, unless you're being paid by the hour, you want to avoid record locking just because it creates more work for you.

Record Locking Is Evil: Reason No. 2
The second reason that you don't want to lock records is because it reduces the scalability of your application.

There are two reasons for this. First, as more users access your application, the more likely it is that two users will attempt to access the same record. If the first user on the scene has locked the record, then the second user will either have their code idle while waiting for the lock to be released (soaking up resources on the server) or will simply be told that he can't have the requested record.

Either way, your application is supporting fewer users than if you just sent the data to the second user. And remember, a lot of the time, when you lock a record, the user doesn't change anything and you've annoyed the other users for no reason.

The second way that record locking reduces scalability is simpler: Record locking is hard on the database server. Once you start locking records you'll find that just about all of your performance measures get worse even if the number of users doesn't increase.

When it comes to record locking, just say "No."

What Not To Do
But as I noted at the start, because the ASP.NET DataSources update every field in a record, you do need to handle record contention. There are two solutions which I've discussed here and here.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at

comments powered by Disqus


  • Uno Platform Ports Windows Calculator to Linux

    Uno Platform has ported the famed Windows Calculator, open sourced last year, to Linux as part of a continuing "proof point" effort to demonstrate the reach of what it describes as the sole UI offering available to target Windows, WebAssembly, iOS, macOS, Android and Linux with single-codebase applications coded in C# and XAML.

  • ASP.NET Core OData 8 Preview Supports .NET 5, but with Breaking Changes

    ASP.NET Core OData, which debuted in July 2018, is out in a v8.0 preview that for the first time supports the upcoming .NET 5 milestone release.

  • VS Code Java Team Details 5 Best Dev Practices

    Microsoft's Visual Studio Code team for Java development added a new Coding Pack for Java installer and detailed best practices for setting up a development environment.

  • Binary Classification Using PyTorch: Defining a Network

    Dr. James McCaffrey of Microsoft Research tackles how to define a network in the second of a series of four articles that present a complete end-to-end production-quality example of binary classification using a PyTorch neural network, including a full Python code sample and data files.

  • Blazor Debugging Boosted in .NET 5 RC 2

    In highlighting updates to ASP.NET Core in the just-launched second and final Release Candidate of .NET 5, Microsoft pointed out better debugging for Blazor, the red-hot project that allows for C# coding of web projects.

Upcoming Events