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/D2CE8C...F9C828B30.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 JobSubmittedHan dler JobSubmittedEve nt; // wire up the delegate as
well
event JobInProgressHa ndler JobInProgressEv ent; // wire up the delegate
as well
event JobFailedHandle r JobFailedEvent; // wire up the delegate as well
event JobCompletedHan dler JobCompletedEve nt; // 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.
...
"Paul" <li****@gmail.c omwrote in message
news:dd******** *************** ***********@e6g 2000prf.googleg roups.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.
