-2

In a web application that fires of many ajax requests from different users to carry out actions. One of these requests fires off some database updates. If this is currently in progress I want to make sure other session requests for this action is just ignored. Is it safe to implement a static variable that I can lock so the action can be ignored by other requests if one is already in progress or would this just be a bad design?

Update

After digging more I came across Optimistic Concurrency. I'm using EF6 so to avoid this it sounds like all I need to do is with Concurrency Mode to fixed?

Tsukasa
  • 6,342
  • 16
  • 64
  • 96
  • Why wouldn't it be "safe"? –  Jan 23 '17 at 14:10
  • What you're asking here is really vague. What is this "action" you want other requests to "ignore"? What is currently happening when you don't "ignore" that "action"? Please read [ask]. – CodeCaster Jan 23 '17 at 14:11
  • I didn't think it would be. Just always seem to read to try an avoid static in a web application. So there would be no issues then? – Tsukasa Jan 23 '17 at 14:11
  • 3
    What will happen when your app is ever installed on 2 or more servers? What do you want to happen? – H H Jan 23 '17 at 14:12
  • @HenkHolterman Now that is a good point. I want to avoid certain database updates if there is a user already performing them. – Tsukasa Jan 23 '17 at 14:16
  • I have updated my question. – Tsukasa Jan 23 '17 at 14:17
  • What you need is syncronization at the database level and the application level. There are various ways to do this but can be db implementation specific (ie. sql-server, oracle, mysql, etc.). Ie. in Sql Server you can use a `rowversion` column on a table and in the app you can handle exceptions (depending on ORM framework or Ado.net), and send that back to the client. The client sends their rowversion value with any updates and gets an updated version back OR error if there was onother change that took place first. – Igor Jan 23 '17 at 14:19
  • @Igor this would be mssql. – Tsukasa Jan 23 '17 at 14:20

1 Answers1

2

A solution based on static variables may look attractive, because it is easy to implement. However, it quickly becomes a maintenance liability, particularly in a web application environment.

The problem with static variables in web environments, such as IIS, is that they are not shared globally across your entire application: if you configure your app pool to have several worker processes, each process would have its own copy of all static variables. Moreover, if you configure your infrastructure for load balancing, each process on each server would have its own copy, with no control on the part of your application. In your situation this would mean a possibility of multiple updates happening at the same time.

That is why I would avoid using a static variable in situations when it is absolutely critical that at most a single request be in progress at any given time.

In your situation, the persistence layer should be in charge of not corrupting the data no matter how many updates are firing at the same time. Persistence layer needs to decide which requests to execute, and which to throw away. One approach to solving this problem is optimistic locking. See this Q&A for general information on how it could be implemented.

Community
  • 1
  • 1
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • That is what I thought. After digging more I cam across Optimistic Concurrency. I'm using EF6 so to avoid this it sounds like all I need to do is with `Concurrency Mode` to fixed? – Tsukasa Jan 23 '17 at 14:27
  • @Tsukasa Yes, optimistic concurrency of EF6 is a good tool for addressing this issue. – Sergey Kalinichenko Jan 23 '17 at 14:31