Nebi-Question: Database-Cronjob or Threading-Solution

[Christian Schlemmer]

Hi,

in a webapplication, after a submit a page is called which is processing
images uploaded by the user. currently after submit a status bar will be
visible (the page for the image processing runs in an iframe) and after
image processing the page makes an redirect. if there are many images, the
processing needs some time and if the user is closing the browser the
processing will be interrupted.

now i would like to source out the image-processing to make it
"barrier-free". my idea was to write after submit the sessionId (foldername
with images = sessionId) to a database and read the database with a cronjob
to process the images.

i have heard from threading and that it should be possible to store a thread
in memory even if the user is closing the browser. is it true, that a
method-call can be saved in a thread, or would the database-cronjob-solution
be better?

thank you very much.

Regards,
Christian

[Alberto Poblacion]

"Christian Schlemmer" <ch************ *****@iplace.at wrote in message
news:ew******** *****@TK2MSFTNG P02.phx.gbl...

in a webapplication, after a submit a page is called which is processing
images uploaded by the user. currently after submit a status bar will be
visible (the page for the image processing runs in an iframe) and after
image processing the page makes an redirect. if there are many images, the
processing needs some time and if the user is closing the browser the
processing will be interrupted.

now i would like to source out the image-processing to make it
"barrier-free". my idea was to write after submit the sessionId
(foldername with images = sessionId) to a database and read the database
with a cronjob to process the images.

i have heard from threading and that it should be possible to store a
thread in memory even if the user is closing the browser. is it true, that
a method-call can be saved in a thread, or would the
database-cronjob-solution be better?

Well, you *can* create a Thread from the code-behind of a web page, and
the thread will continue to run after the page has been unloaded. However,
this will not scale well. If you have lots of users and your code continues
spawning threads on the server, you are likely to bring the server down.
The alternative is better, i.e., enqueue all the processing requests,
regardless of which mechanism you use to suport the queue (a table in a
database, or a set of files on disk, or MSMQ, or Sql Server Service Broker),
and then run a single process to dequeue and process the request.
We don't have "cron" on Windows; the equivalent would be the windows
scheduler, but for this application I think that it would be better to write
a Windows Service and have the service listen to the queue and process the
jobs as soon as they arrive.

[Christian Schlemmer]

Thank you very much for your helpfull response.
"Alberto Poblacion" <ea************ *************** ***@poblacion.o rgschrieb
im Newsbeitrag news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

"Christian Schlemmer" <ch************ *****@iplace.at wrote in message
news:ew******** *****@TK2MSFTNG P02.phx.gbl...

>in a webapplication, after a submit a page is called which is processing
images uploaded by the user. currently after submit a status bar will be
visible (the page for the image processing runs in an iframe) and after
image processing the page makes an redirect. if there are many images,
the processing needs some time and if the user is closing the browser the
processing will be interrupted.

now i would like to source out the image-processing to make it
"barrier-free". my idea was to write after submit the sessionId
(foldername with images = sessionId) to a database and read the database
with a cronjob to process the images.

i have heard from threading and that it should be possible to store a
thread in memory even if the user is closing the browser. is it true,
that a method-call can be saved in a thread, or would the
database-cronjob-solution be better?

Well, you *can* create a Thread from the code-behind of a web page, and
the thread will continue to run after the page has been unloaded. However,
this will not scale well. If you have lots of users and your code
continues spawning threads on the server, you are likely to bring the
server down.
The alternative is better, i.e., enqueue all the processing requests,
regardless of which mechanism you use to suport the queue (a table in a
database, or a set of files on disk, or MSMQ, or Sql Server Service
Broker), and then run a single process to dequeue and process the request.
We don't have "cron" on Windows; the equivalent would be the windows
scheduler, but for this application I think that it would be better to
write a Windows Service and have the service listen to the queue and
process the jobs as soon as they arrive.

[Christian Schlemmer]

i did some research and have some questions i would like to ask:

Do you mean the Queue-Class form System.Collecti ons with its methods Enqueue
and Dequeue?
The single process to dequeue and process the request is the
Windows-Service, right?
summing up, if i understood correct it works like follows: After submit a
job is enqueued to a queue-object (regardless if the user is closing the
browser it will be reside in memory) and a Windows Service is listening if
there are objects ob type queue in the memory and if yes it starts to deqeue
the objects, right?

Thank you & regards


"Alberto Poblacion" <ea************ *************** ***@poblacion.o rgschrieb
im Newsbeitrag news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

"Christian Schlemmer" <ch************ *****@iplace.at wrote in message
news:ew******** *****@TK2MSFTNG P02.phx.gbl...

>in a webapplication, after a submit a page is called which is processing
images uploaded by the user. currently after submit a status bar will be
visible (the page for the image processing runs in an iframe) and after
image processing the page makes an redirect. if there are many images,
the processing needs some time and if the user is closing the browser the
processing will be interrupted.

now i would like to source out the image-processing to make it
"barrier-free". my idea was to write after submit the sessionId
(foldername with images = sessionId) to a database and read the database
with a cronjob to process the images.

i have heard from threading and that it should be possible to store a
thread in memory even if the user is closing the browser. is it true,
that a method-call can be saved in a thread, or would the
database-cronjob-solution be better?

Well, you *can* create a Thread from the code-behind of a web page, and
the thread will continue to run after the page has been unloaded. However,
this will not scale well. If you have lots of users and your code
continues spawning threads on the server, you are likely to bring the
server down.
The alternative is better, i.e., enqueue all the processing requests,
regardless of which mechanism you use to suport the queue (a table in a
database, or a set of files on disk, or MSMQ, or Sql Server Service
Broker), and then run a single process to dequeue and process the request.
We don't have "cron" on Windows; the equivalent would be the windows
scheduler, but for this application I think that it would be better to
write a Windows Service and have the service listen to the queue and
process the jobs as soon as they arrive.

[Alberto Poblacion]

"Christian Schlemmer" <ch************ *****@iplace.at wrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Do you mean the Queue-Class form System.Collecti ons with its methods
Enqueue and Dequeue?

No, that was not what I had in mind. The Queue class would keep the
queue items in memory inside a .Net process, so it doesn´t provide an easy
way to move the items from the web pages code-behind into the Service. But
now that you mention it, it may be a good solution, since you could keep the
queue inside the service, using a System.Collecti ons.Queue, and implement
some interprocess communication to send the requests from the web pages into
the service, which would enqueue them upon receipt, and keep a (single)
separate thread dequeuing and processing requests.

The single process to dequeue and process the request is the
Windows-Service, right?

Yes.

summing up, if i understood correct it works like follows: After submit a
job is enqueued to a queue-object (regardless if the user is closing the
browser it will be reside in memory) and a Windows Service is listening if
there are objects ob type queue in the memory and if yes it starts to
deqeue the objects, right?

Yes, after submitting a job it is immediately sent to the queue, so the
page can then be closed, and the Windows Service listens on the queue. At
first my idea was to submit the jobs to a separate storage (such as, for
example, Microsoft Message Queue Service (MSMQ)), and have the Windows
Service extract the jobs from the same storage. In this way, MSMQ (or
whatever you used in its place) would provide the communication between web
and service, without requiring a separate interprocess communication.

[Christian Schlemmer]

Hi Alberto,

Thank you very much, for your answers.

best regards,
Christian

"Alberto Poblacion" <ea************ *************** ***@poblacion.o rgschrieb
im Newsbeitrag news:es******** ******@TK2MSFTN GP03.phx.gbl...

"Christian Schlemmer" <ch************ *****@iplace.at wrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

>Do you mean the Queue-Class form System.Collecti ons with its methods
Enqueue and Dequeue?

No, that was not what I had in mind. The Queue class would keep the
queue items in memory inside a .Net process, so it doesn´t provide an easy
way to move the items from the web pages code-behind into the Service. But
now that you mention it, it may be a good solution, since you could keep
the queue inside the service, using a System.Collecti ons.Queue, and
implement some interprocess communication to send the requests from the
web pages into the service, which would enqueue them upon receipt, and
keep a (single) separate thread dequeuing and processing requests.

>The single process to dequeue and process the request is the
Windows-Service, right?

Yes.

>summing up, if i understood correct it works like follows: After submit a
job is enqueued to a queue-object (regardless if the user is closing the
browser it will be reside in memory) and a Windows Service is listening
if there are objects ob type queue in the memory and if yes it starts to
deqeue the objects, right?

Yes, after submitting a job it is immediately sent to the queue, so the
page can then be closed, and the Windows Service listens on the queue. At
first my idea was to submit the jobs to a separate storage (such as, for
example, Microsoft Message Queue Service (MSMQ)), and have the Windows
Service extract the jobs from the same storage. In this way, MSMQ (or
whatever you used in its place) would provide the communication between
web and service, without requiring a separate interprocess communication.