On 5/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 5/11/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> On 5/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > On 5/11/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > > Also, is it possible to lock the server-side bean on a framework
> > > level, so it would be guaranteed that the bean won't get second
> > > request until the first one is serviced and responded to? Will a
> > > simple "synchronized" do?
> >
> >
> > Synchronizing might work *if* you were talking about the same instance
> of
> > the backing bean -- but that is not going to be effective if you are
> using
> > request scoped backing beans. In Struts terms, it would be like trying
> to
> > synchronize on a property setter of a request-scoped ActionForm -- that
> will
> > not catch the "duplicate submit" scenario because each request woud get
> its
> > own instance.
>
> Yep, I meant session-scoped beans. JSF is more tolerant to
> session-scoped beans than Struts, or even prefers them over request
> scoped. So this might work.
Might indeed (although you would still need the server side logic to detect
the second submit and ignore it somehow), but I'd likely want to have a
client side solution in place too, even if I implemented this, to improve
the user experience.
Is it possible to put all incoming requests into the map, so after a
request has been serviced (response has been returned to the browser),
it is removed from the map. When another request comes, we can use
either soft comparison (same base URL) or strong comparison (same URL
+ params + method). If the incoming request is in the map already, we
wait for response and return it in the same thread as the latter
request (client has abandoned the first request anyway). So, we would
need a separate map-controlling thread. Incoming threads would wait on
request instance in the map. When response is ready, all threads but
the last one would be terminated, the last one would return the
response. Um, maybe instead of a map of requests it should rather be a
map with lists of similar requests...
Just a thought. The point is: do not process the "same" (whatever
"same" is) request until the prior one has been serviced.
only store session scoped state for cases where I need it for a
defined period of time (i.e. the conversational state in a Shale Dialog, for
example, where it'll get thrown away for me when the dialog is completed).
How do you know that dialog is completed? :-) What if a user hasn't
clicked "Done" or "Cancel"? Do you have a window close event listener
or something or a page change listener? Anyway, Struts Dialogs wizard
sample works the same ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
