I have 2 applications, one an ASP.NET site the user interfaces with, and then a second C# application that schedules jobs for execution. I’m having trouble with change tracking in the C# application, so that it can respond to updates to the database from the user. The basic idea is this:
The user adds a new row to the Products database via the ASP.NET website. The C# application should then be notified of the new row, and it will spawn a Quartz.NET job to do something with this newly created product. If the product details are updated, the C# application is notified and updates the Quartz.NET job appropriately.
Pseudocode:
while(true) // it's not really a loop like this, but this suffices
{
var newProducts = from p in dc.Products where Added_On > DateTime.Now;
foreach(Product product in newProducts)
CreateNewJob(product);
}
Then, each job is required for tracking changes to it’s individual column:
void Execute(...)
{
var product = from p in dc.Products where Id == this._product.Id;
if (CompareProduct(this._product, product) == false)
_product = product;
// do work with the product
}
or with a timestamp:
void Execute(...)
{
var updated = from p in dc.Products where Id == _product.Id && Updated_On > DateTime.Now;
if (updated != null)
_product = updated;
}
Since more often than not, the product’s won’t be changing, is there a better solution than to query for changes every time it executes?
The requirement is that if the data has changed, the Quartz.NET job should not execute with stale data. At the beginning of Execute() it should be the most recent changes. It is OK if the state changes during execution though.
I’ve looked at SqlDependency, but everything I’ve read says it does not tell you what changed, only that something changed. It seems infeasible for a large database to constantly pull down the full table, and do the comparison myself.
Change tracking also seems that it might be inefficient. I’d have to pull down all the changes, find the Quartz.NET job corresponding to the changed item, and update it with the most recent data.
Probably the best way is to do this the old-fashoined way — use the sql TIMESTAMP column to do the change tracking yourself. Then your scheduler only need grab rows where TIMESTAMP is > [last runned TIMESTAMP] to schedule. When scheduled, it can check the row to see if the TIMESTAMP has changed and grab the new data before running.
Now, if you’ve got multiple tables to worry about, this gets to be a bit more complex.