2

I have a project which provides users with a list of current tasks that need to be completed. Any user can complete any task, and so to ensure that only one user is working on a task at a time I need to be able to 'lock' it. I'm using SignalR for this, so a user requests a lock on a task, and if they are successful (ie. if noone else has locked it) then they will be able to access the further information that they need.

My problem is how to store the list of locked tasks. The original plan was simply to add an additional bit field 'IsLocked' to the Task table and update this when the user requested a lock and when the task was unlocked. We have about 300 concurrent users, however, and a task takes only about 3-4 minutes, meaning huge numbers of additional - and tiny - queries on the database. Therefore we were wondering about in-memory storage, simply storing a list of task ids in a 'lockedTasks' list.

I had considered using caching, but am unsure on the best ways to do this, or even if better alternatives exist. If anyone has any experience in this then some advice would be great thanks

Jordan Wallwork
  • 3,116
  • 2
  • 24
  • 49

3 Answers3

2

I would avoid memory completely as IIS is not that great with it, if you found your self in the IIS need for refreshing the Application Pool for some sort of reason, your list is simply gone!

Maybe a MemCache system? If it does not loose things in the above way, but...

I would advice to be in the middle, IO File is fast that request data to a Database, specially if it's not in the same machine (witch for security reasons, it should never be), so... why not, and just to hold your list, you don't use one of the currently famous NoSQL database?

MongoDB is a document database that has a .NET Library and it's easy to use, it is not as fast as Memmory, but extremely quicker than Physical databases for what you want.

Normally the NoSQL Database will be hosted in the App_Data folder so it will be extremely fast to access and you can just hold there the task_id and user_id of all locked tasks.

balexandre
  • 73,608
  • 45
  • 233
  • 342
2

Have you considered stateful filters?

Check out this links for more info:

frennky
  • 12,581
  • 10
  • 47
  • 63
0

I'm sorry, but if your app can't handle a single query every 3-4 minutes x 300 users, then you're doing something very wrong. Just browsing a site typically generates orders of magnitude more queries than that.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • BTW: the count is 300 queries between 3 to 4 minutes, and can't be a single query, they have to be much more, `GET_USER`, `GET_TASK_DETAILS`, etc... :) but if it's **correctly** set up, I see no problem except the need for the improving an already good job ;) – balexandre Sep 30 '11 at 08:47
  • No I realise that alone is not a hugely significant amount, but all these extra calls are additional load on top of what the app is doing already. I don't want to place extra burden on the database if I don't really need to – Jordan Wallwork Sep 30 '11 at 09:00
  • I agree with @MystereMan. Aren't you optimizing too early? – JefClaes Sep 30 '11 at 10:35