The type of behaviour you are describing is called pessimistic concurrency. You haven't said if you need this lock to get locked within a single web request or across multiple requests. Rather than reinventing the wheel, you should use standard concurrency techniques, and read up on how you implement those for .net.
Typically web applications use optimistic concurrency; if you need pessimistic concurrency it gets very hard very quickly. ASP.NET does not offer out of the box support for pessimistic concurrency.
You haven't said how you access your database (e.g. if you are using ADO.NET, or EF), but EF also has concurrency control. Ultimately it comes down to using transaction objects such as SqlTransaction to coordinate the updates across tables, being able to check to see if another user beat you to the update, and if they did then deciding what to do.
With pessimistic concurrency you have a whole lot more to worry about - where to put your global lock (e.g. in the code) what happens if that goes wrong (e.g. recycling of application pools in IIS can mean that two users don't lock the same object if your lock is in a code-based singleton) and how to deal with timeouts if you record locks in your database. If you want to see another SO question related to pessimistic concurrency, see: How do I implement "pessimistic locking" in an asp.net application?
Edit. I should also have mentioned that if you are already building logic for building objects and saving them to the db then you should be aware of the Repository and Unit of Work patterns. If not, then you should read about those as well. You are solving a standard problem that has standard patterns to implement those solutions in most languages.
