struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. Cekvenich" <v...@users.sourceforge.net>
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
bean.getDAO().saveAsyc();

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
http://gee.cs.oswego.edu/dl/classes/collections

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


hth,
.V



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 somePage.do
> 2) javascript puts "somePage.do" in hidden field on currentPage, and
>        then initiates a submit of currentPage
> 3) submit to currentPageSave.do
> 3) action forwards to jsp with hidden form -- 'somePage.do' 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:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message