7

I'm currently in the process of building an ASP.NET MVC web application in c#.

I want to make sure that this application is built so that it can scale out in the future without the need for major re-factoring.

I'm quite keen on using some sort of queue to post any writes to my database base to and have a process which polls that queue asynchronously to perform the update. Once this data has been posted back to the database the client then needs to be updated with the new information. The implication here being that the process to write the data back to the database could take a short while based on business rules executing on the server.

My question is what would be the best way to handle the update from the client\browser perspective.

I'm thinking along the lines of posting the data back to the server and adding it to the queue and immediately sending a response to the client then polling at some frequency to get the updated data. Any best practices or patterns on this would be appreciated.

Also in terms of reading data from the database would you suggest using any particular techniques or would reading straight from db be sufficient given my scenario.

Update Thought I'd post an update on this as it's been a while. We've actually ended up using Windows Azure but the solution is applicable to other platforms.

What we've ended up doing is using the Windows Azure Queue to post messages\commands to. This is a very quick process and returns immediately. We then have a worker role which processes these messages on another thread. This allows us to minimize any db writes\updates on the web role in theory allowing us to scale more easily.

We handle informing the user via emails or even silently depending on the type of data we are dealing with.

gsobocinski
  • 295
  • 3
  • 10
  • My first question with this would be why do you want to make your database writes asynchronous if you then leave your users waiting for the results to be written? – Jack Ryan May 27 '09 at 15:29
  • My problem is that there may be a business rule that runs, similar to a db trigger, for a period of time. While this might be ok for a small number of users I see this as a bottle neck which could potentially lead to user requests timing out on the client which is something I want to avoid. – gsobocinski May 27 '09 at 15:43

5 Answers5

2

Not sure if this helps but why dont you have an auto refresh on the page every 30 seconds for example. This is sometimes how news feeds work on sports websites, saying the page will be updated every x minutes.

<meta http-equiv="refresh" content="120;url=index.aspx">
David
  • 15,150
  • 15
  • 61
  • 83
1

Why not let the user manually poll the status of the request? This is how your typical e-commerce app is implemented. When you purchase something online, the order is submitted to a queue for fullfillment. After it's submitted, the user is presented with a "Thank you for your order" page and a link where they can check the status of the order. The user can visit the link anytime to check the status, no need for an auto-poll mechanism.

Is your scenario so different from this?

dso
  • 9,463
  • 10
  • 53
  • 59
  • Thanks, but I don't think this will fit in with the application. It might be useful to say that this is more of a line of business app where users won't always want to have to go back and check on the status of something. Generally speaking I prefer to automate as much as possible for the user as well. – gsobocinski May 28 '09 at 10:49
  • @gsobocinski - I think DSO makes a good point. If you have transactions that the user can expect to be short, then have the request directly update the DB, and immediately update the UI. However, for the transactions that can take a while to complete, let the user know that, and instruct them to check periodically for the results. – mbeckish Nov 09 '10 at 02:51
0

While I don't know if I agree with the logic of why, I do know that something like jQuery is going to make your life a LOT easier. I would suggest making a RESTful web API that your client-side code consumes. For example, you want to post a new order to the system and have the client responsive? Make a post to www.mystore.com/order/create and have that return the new URI to access the order (i.e. order#) as a URI (www.mystore.com/order/1234). That response is then stored in the client code and a jQuery call is setup to poll for a response or stop polling on an error.

For further reading check out this Wikipedia article on the concept of REST.

Additionally you might consider the Reactive Extensions for .NET and within that check out the RxJS sub-project which has some pretty slick ways of handling with the polling problem without causing you to write the polling code yourself. Fun things to play with!

Community
  • 1
  • 1
Norman H
  • 2,248
  • 24
  • 27
0

Maybe you can add a "pending transactions" area to the UI. When you queue a transaction, add it to the user's "pending transactions" list.

When it completes, show that in the user's "pending transactions" list the next time they request a new page.

You can make a completed transaction stay listed until the user clicks on it, or for a predetermined length of time.

mbeckish
  • 10,485
  • 5
  • 30
  • 55
0

Sorry in my previous answer I might have misunderstood. I was talking of a "queue" as something stored in a SQL DB, but it seems on reading your post again you are may be talking about a separate message queueing component like MSMQ or JMS?

I would never put a message queue in the front end, between a user and backend SQL DB. Queues are good for scaling across time, which is suitable between backend components, where variances in processing times are acceptable (e.g. order fulfillment)... when dealing with users, this variance is usually not acceptable.

dso
  • 9,463
  • 10
  • 53
  • 59
  • The idea behind using the message queue was to free up the asp.net worker process from any potentially blocking I\O, db writes in my case. I've read a few articles which suggest using this is a good method to scale web applications and removes some dependency between the web front end and my application tier. Of course you would need to do something with the UI to negate the fact that things are being queued to make it immediately responsive, which is probably pushing me more towards an AJAX like approach. For example on a post having some kind of "Please Wait" graphic. – gsobocinski Jun 02 '09 at 14:48