This is an old and abandoned application block.
http://msdn2.microsoft.com/en-us/library/ms998466.aspx but you might want to take a look for ideas.
...............
Several years back, I worked for a company that modified this block.
They had about 4 status.
Submitted
Working
Failed
Completed.
The results were always in a generated html file.
Once you submitted a request (for a long running report)...you were sent to
a screen that showed all your requests.
The one you just added....showed up and usually it was "Working" (maybe
Submitted if the Queue was backlogged)
So once it was "Completed", you would get a link....to a "double guid" html
file.
example
http://www.mysite.com/reports/D2CE8CCD6B984d32A7642A03F5810000/AAAA6B35CCA74bd1A5A895BF9C828B30.html its hard to see, but there are 2 guids..one is a directory, one is a
filename.
We had a clean up script that would delete files (and db entries) for
reports older than 2 weeks.
And we also optionally email you when the report was finished. We put your
email address in a cookie...but it was optional.
It worked pretty good.
It I were doing it today....I might keep the idea of the application block.
But I'd use WCF (IsOneWay) messages.
And I'd write a common interface...and would definately wire up events
public interface ILongRunning
event JobSubmittedHandler JobSubmittedEvent; // wire up the delegate as
well
event JobInProgressHandler JobInProgressEvent; // wire up the delegate
as well
event JobFailedHandler JobFailedEvent; // wire up the delegate as well
event JobCompletedHandler JobCompletedEvent; // wire up the delegate as
well
(or something like that)
then you can keep the implementation seperate from the handling of
events,.which would write to a db log and/or email people.
I'm talking free-lance here, so take anything I say with a grain of salt.
...
[quoted text, click to view] "Paul" <listnz@gmail.com> wrote in message
news:dd6c19d5-de81-4b17-b492-11c995444d90@e6g2000prf.googlegroups.com...
>I have decided on a basic architechture to quickly refactor two
> processing functions of my winforms application until we get the
> chance to rewrite it. Basically it will consist of 2 applications:-
>
> 1. A service running on the server to take jobs from a queue table in
> a SQL database, perform the job (could be 1 minute or up to an hour or
> more) and write the results back to the database.
>
> 2. A .NET web application to submit the job requests into the queue
> table. (Initially a combo box with a button marked "Process".)
>
> One thing we hope to achieve with this is I would like to keep the
> door open to have multiple servers all processing simultaneously
> should that become necessary (as we hope it will!). Another thing is
> decoupling of the components - eg the server crashes and it (or other
> servers) will continue to process jobs on restart as they are queued
> safely in the database, while clients can continue to submit jobs and
> perform other work.
>
> My question is, should I worry about giving feedback to the client
> application and if so how? Two alternatives with minimal overheads
> might be
> 1. Email the client to say "Your job has completed".
> 2. Write progress info to the database for the web app to pickup and
> display back to the client
>
> Given the jobs could run a long time and the user may just wish to
> close the browser and move on, is it worth writing code (and
> processing overhead) to inform him of progress with one of the one
> minute type jobs?
>
> Your thoughts on this question or the architecture decisions in
> general would be much appreciated.
>
> cheers,
> Paul.
>
>
>
>
