Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > background process: existing jsp/servlet or new applet?

Reply
Thread Tools

background process: existing jsp/servlet or new applet?

 
 
robert
Guest
Posts: n/a
 
      10-22-2004
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
 
Reply With Quote
 
 
 
 
Bryce
Guest
Posts: n/a
 
      10-22-2004
On 22 Oct 2004 11:25:30 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (robert) wrote:

>- 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.

--
now with more cowbell
 
Reply With Quote
 
 
 
 
John C. Bollinger
Guest
Posts: n/a
 
      10-22-2004
robert wrote:

> 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 Removed)
 
Reply With Quote
 
Will Hartung
Guest
Posts: n/a
 
      10-22-2004
"robert" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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
((E-Mail Removed))





 
Reply With Quote
 
robert
Guest
Posts: n/a
 
      10-23-2004
Bryce <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
> On 22 Oct 2004 11:25:30 -0700, (E-Mail Removed) (robert) wrote:
>
> >- 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.


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.
 
Reply With Quote
 
robert
Guest
Posts: n/a
 
      10-23-2004
"John C. Bollinger" <(E-Mail Removed)> wrote in message news:<clbtbm$mlt$(E-Mail Removed)>...
> robert wrote:
>
> > 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 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
 
Reply With Quote
 
Bryce
Guest
Posts: n/a
 
      10-25-2004
On 22 Oct 2004 20:07:34 -0700, (E-Mail Removed) (robert) wrote:

>Bryce <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
>> On 22 Oct 2004 11:25:30 -0700, (E-Mail Removed) (robert) wrote:
>>
>> >- 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.

>
>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...)

--
now with more cowbell
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Existing Dll - using Functions from an existing dll Tristin.Colby@gmail.com Ruby 0 02-05-2008 07:38 PM
not able to click on background tab and backgrounds in properties to change the background. rex Computer Support 2 12-06-2006 02:26 AM
Background transparent when 'background' is used JWL HTML 4 09-26-2006 05:37 PM
Background Check - Background search - People search mason66 ASP .Net 0 07-27-2006 10:20 AM
Why no existing Java type to existing XML schema binding support? nrm Java 3 04-10-2006 04:52 PM



Advertisments