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. IMHO, session scoped backing beans in JSF have the same set of problems (as well as the same set of potential benefits) as session scoped form beans in Struts -- so the same tradeoff decisions apply in both cases. Personally, I try to use request scope for JSF backing beans (i.e. the equivalent of Action+ActionForm, or what WW2 considers to be an action instance) in my apps, and 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). Craig
