background process: existing jsp/servlet or new applet?

Discussion in 'Java' started by robert, Oct 22, 2004.

  1. robert

    robert Guest

    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
     
    robert, Oct 22, 2004
    #1
    1. Advertising

  2. robert

    Bryce Guest

    On 22 Oct 2004 11:25:30 -0700, (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
     
    Bryce, Oct 22, 2004
    #2
    1. Advertising

  3. 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
     
    John C. Bollinger, Oct 22, 2004
    #3
  4. robert

    Will Hartung Guest

    "robert" <> wrote in message
    news:...
    > 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
    ()
     
    Will Hartung, Oct 23, 2004
    #4
  5. robert

    robert Guest

    Bryce <> wrote in message news:<>...
    > On 22 Oct 2004 11:25:30 -0700, (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.
     
    robert, Oct 23, 2004
    #5
  6. robert

    robert Guest

    "John C. Bollinger" <> wrote in message news:<clbtbm$mlt$>...
    > 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
    >


    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
     
    robert, Oct 23, 2004
    #6
  7. robert

    Bryce Guest

    On 22 Oct 2004 20:07:34 -0700, (robert) wrote:

    >Bryce <> wrote in message news:<>...
    >> On 22 Oct 2004 11:25:30 -0700, (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
     
    Bryce, Oct 25, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Miguel De Anda
    Replies:
    3
    Views:
    11,341
    Ivan S Kirkpatrick
    Jul 3, 2003
  2. circuit_breaker
    Replies:
    2
    Views:
    2,081
    Jack Jia
    Apr 4, 2004
  3. Tedy
    Replies:
    1
    Views:
    470
    Andrew Thompson
    Aug 4, 2005
  4. javadev
    Replies:
    5
    Views:
    13,086
    javadev
    Nov 16, 2006
  5. Replies:
    4
    Views:
    839
Loading...

Share This Page