background process: existing jsp/servlet or new applet?

[robert]

given an existing code base of jsp/servlet ala Struts; how best
(efficiency of execution secondary, getting the code done primary) to
support background processing: spec. database writes??

- post to the controller servlet which spawns a thread to do the db
update, then sends a response back to the browser. all using the
existing infrastructure. adv.: the application comes back fast.
disadv.: one loses contact with the db update, so confirming that
it worked is some work.

- add an applet, which spawns a thread to do the db update. adv.: the
applet can keep track of the update, and can respond with update
status with a bit less work. disadv.: integrating the applet with
the existing L&F of the jsp.

oddly (it seems to me), i can't find any discussions of these alternatives,
either on c.l.j or various servlet texts.

BobTheDataBaseBoy

 

[Bryce]

- post to the controller servlet which spawns a thread to do the db
update, then sends a response back to the browser. all using the
existing infrastructure. adv.: the application comes back fast.
disadv.: one loses contact with the db update, so confirming that
it worked is some work.

We do exactly this (using ThreadPools and worker threads). You lose
track in that its an asynchronous transaction. A status page retrieves
the data, to view if the transaction was successful.

 

[John C. Bollinger]

given an existing code base of jsp/servlet ala Struts; how best
(efficiency of execution secondary, getting the code done primary) to
support background processing: spec. database writes??

- post to the controller servlet which spawns a thread to do the db
update, then sends a response back to the browser. all using the
existing infrastructure. adv.: the application comes back fast.
disadv.: one loses contact with the db update, so confirming that
it worked is some work.

- add an applet, which spawns a thread to do the db update. adv.: the
applet can keep track of the update, and can respond with update
status with a bit less work. disadv.: integrating the applet with
the existing L&F of the jsp.

oddly (it seems to me), i can't find any discussions of these alternatives,
either on c.l.j or various servlet texts.

You sure have a slow DB update going on if the servlet can't just wait
until the update is done to respond. Are you sure you're not making
work that doesn't need to be done? Does the client actually need to
know when the background job has finished?

Supposing that you really do need to do this sort of thing, a solution I
have seen before is that the server sends a page containing an "in
progress" message to the client; the page auto-refreshes every few
seconds until the background work is complete; and then the client gets
a page with a "job complete" message. I would recommend against trying
to work up an applet specifically for this task; it would be way more
trouble than it's worth.


John Bollinger
(e-mail address removed)

 

[Will Hartung]

given an existing code base of jsp/servlet ala Struts; how best
(efficiency of execution secondary, getting the code done primary) to
support background processing: spec. database writes??

- post to the controller servlet which spawns a thread to do the db
update, then sends a response back to the browser. all using the
existing infrastructure. adv.: the application comes back fast.
disadv.: one loses contact with the db update, so confirming that
it worked is some work.

- add an applet, which spawns a thread to do the db update. adv.: the
applet can keep track of the update, and can respond with update
status with a bit less work. disadv.: integrating the applet with
the existing L&F of the jsp.

We used an auto-refreshing hidden frame. We create the process, give it an
ID, spit off a thread, and then the process updates a database row (in a
seperate transaction) using the ID, and then we have the auto-refreshing
hidden frame query the servlet layer and then update the displayed frame
based on what it gets from the status table. When it completes, we redirect
to the result page.

This technique will work whether you run the process in a seperate thread,
or spit it out to a handy JMS server to do the processing.

Regards,

Will Hartung
([email protected])

 

[robert]

We do exactly this (using ThreadPools and worker threads). You lose
track in that its an asynchronous transaction. A status page retrieves
the data, to view if the transaction was successful.

that was my inclination. i guess i'll have to fight to the death to
kill off the applet wave. not that applets are necessarily bad (another
system is applet based), but mixing one in just to get threading seems
foolish.

after i posted, and continued chewing on the problem, it seems that
threading in an applet presents an issue with killing off the thread in
the client if the user closes the browser or windoze locks up (not
much chance of that, right). server side threading looks the better
way.

 

[robert]

You sure have a slow DB update going on if the servlet can't just wait
until the update is done to respond. Are you sure you're not making
work that doesn't need to be done? Does the client actually need to
know when the background job has finished?

Supposing that you really do need to do this sort of thing, a solution I
have seen before is that the server sends a page containing an "in
progress" message to the client; the page auto-refreshes every few
seconds until the background work is complete; and then the client gets
a page with a "job complete" message. I would recommend against trying
to work up an applet specifically for this task; it would be way more
trouble than it's worth.


John Bollinger
(e-mail address removed)

i think two options: write to a session object and poll it on each page
transition, updating an icon in the jsp/html; write to a status table in
the database, and so forth.

and yes, the nature of the system is that a *lot* database work can
get spawned from a relatively small amount of data sent over the wire.
back when it was a host/terminal system, not so much of a big deal.
ain't wrapping legacy code a gas????? oy

 

[Bryce]

that was my inclination. i guess i'll have to fight to the death to
kill off the applet wave. not that applets are necessarily bad (another
system is applet based), but mixing one in just to get threading seems
foolish.

Our requirements were that we needed to guarantee delivery and
execution of the process (banking software if funny that way), but
immediate feedback wasn't important. Issue was that hundreds and
thousands of transactions can be taking place. So having an "in
progress" page wasn't feasible. That's where the asynchronous
messaging comes in.

JMS would have been a good technology to use, but design decisions
were made before I came on board. Originally, they had each servlet
request spawning a thread... Imagine having hundreds of requests every
minute or so... A thread for each request would eat resources pretty
darn quick.

I implemented thread pooling using a queue and a finite number of
worker threads. Works great. Processing slows down during peak usage,
but usually a transaction is completed within a few minutes. There are
some tricks we do, s uch as logging the transaction before returning
control to the user. That way, they know the transaction has been
submitted, and we can guarantee that it will be run (again, JMS server
would have been a perfect solution...)