6

I am developing an application using Azure Cloud Service and web api. I would like to allow users that create a consultation session the ability to change the price of that session, however I would like to allow all users 30 days to leave the session before the new price affects the price for all members currently signed up for the session. My first thought is to use queue storage and set the visibility timeout for the 30 day time limit, but this seems like this could grow the queue really fast over time, especially if the message should not run for 30 days; not to mention the ordering issues. I am looking at the task scheduler as well but the session pricing changes are not a recurring concept but more random. Is the queue idea a good approach or is there a better and more efficient way to accomplish this?

user1790300
  • 2,143
  • 10
  • 54
  • 123
  • 1
    Please note that maximum message TTL on Azure Queues is 7 days. – Serdar Ozler Jun 03 '15 at 21:16
  • 1
    I noticed that as well in the article comparing queue storage and service bus queues. In this scenario, is my only available option to put the job in a database table and check every day? This approach seems like a resource drain on the database. – user1790300 Jun 04 '15 at 15:45

3 Answers3

3

The stuff you are trying to do should be done with a relational database. You can use timestamps to record when prices for session changed. I wouldn't use a queue at all for this. A queue is more for passing messages in a distributed system. Your problem is just about tracking what prices changed on what sessions and when. That data should be modeled in a database.

Paul Fryer
  • 9,268
  • 14
  • 61
  • 93
  • This approach seems like it would be the cleanest, but in the azure environment wouldn't I still need to use the scheduler to run each day to find all of the changes? – user1790300 Jun 12 '15 at 12:34
  • Based on your comment "session pricing changes are not a recurring concept but more random" - it sounds like people will be using your API to get pricing information at random times. I suggest using a cache to cache the current prices and have a read through pattern to recompute the new prices if the cache has expired. Once you recompute the new prices put them back in the cache so they can be retrieved quickly at the next call. The timeout you set on the cache should reflect the max amount of time you want to go without recomputing latest prices, several hours to day is probably fine. – Paul Fryer Jun 12 '15 at 18:28
2

I think this scenario is more suitable to use Azure Scheduler. Programatically create a Job with one time recurrence with set date as 30 days later to run once. Once this job gets triggered automatically by scheduler, assign an action to callback to one of your API/Service to do the price & other required updates and also remove this Job from the scheduler as part of this action to have a clean jobs list. Anyways premium plan of Azure Scheduler Job Collection will give you unlimited number of jobs to run.

Hope this is exactly what you were looking for...

Mahesh Jasti
  • 572
  • 3
  • 18
  • 1
    You can see the limits of Azure Scheduler here - https://github.com/Azure/azure-content/blob/master/articles/scheduler-plans-billing.md – Mahesh Jasti Jun 05 '15 at 08:50
2

I would consider using Azure WebJobs. A WebJob basically gives you the ability to run a .NET console application within the context of an Azure Web App. It can be run on demand, continuously, or in response to a reoccurring schedule. If your processing requirements are low and allow for it they can also run in the same process that your Web App is running in to save you $$$ as they are free that way.

You could schedule the WebJob to run once or twice per day and examine the situation and react as is appropriate. Since it's really just a .NET worker role you have ultimate flexibility.

daustinash
  • 496
  • 3
  • 13