struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich" <>
Subject Re: "deferring" an action
Date Thu, 14 Nov 2002 19:10:59 GMT
You are not deferring an action, you are queuing a save.
Most of the time a save is very quick, even with thousands of users, so 
I say just save.

Else consider:

Implement a queue mechanism in you DAO
so you can say

You could write a thread safe singleton collection to append your data 
to, such as rowset, not yet updated and go on with your process.

This requires thread and collection experience, something like

Then spawn another process in container of low priority that remove 
things from the queue, save, sleeps and then remove another.

This make a dirty read possible of course, so you might have to build a 
hashcode of your queue (or even add a cache to the queue).


Alayne Wartell wrote:
> This is something I haven't seen discussed before. Our web application has
> a large, dynamically built tree in its own frame by which users navigate to
> input screens. ( They can also click on menu options -- slightly different
> but raises the same issue for us.) Data entry is freeform -- users can
> navigate anywhere at any time. So far, no big deal. The unusual part is,
> when a user finishes entering data on a screen, then clicks to go to
> another screen, we automatically save the screen they're leaving. In a
> sense, we have to defer the page load action to do a save action on the
> prior page. So we're trying to come up with a clean way to fit this into
> Struts.
> The sequence is:
> Click link -> save current page  -> respond with reassuring message in
> another frame (i.e. "screen has been saved") -> go to clicked link
> We haven't come up with any designs we like yet. One example of something
> we don't like:
> 1) user fills out form, call it currentPage
> 1) user clicks to go to
> 2) javascript puts "" in hidden field on currentPage, and
>        then initiates a submit of currentPage
> 3) submit to
> 3) action forwards to jsp with hidden form -- '' is the form
> action (also, javascript puts confirmation message in header frame)
> 4) immediately submit that form using javascript
> Ideas, anyone? (Sure, we could do away with the auto-save to make our app
> more webbish -- if it weren't a business requirement. Besides, it really is
> nice for the users.)
> Thanks,
> Alayne

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message