JSF – how to handle multiple submissions before rendering the response?

According to the test report, if the response speed is not fast enough, we may press a button many times, resulting in several calls to the back-end code, which we don't want

The application is in GlassFish 3.1 Java EE 6 web profile using JSF 2.0 in 1

I want to know how to handle it properly, and I have considered several situations:

>Submission should disable all buttons using JavaScript when rendering the response. > A flag in the session scope indicates that it is already active, so the sensitive code is skipped and just transferred to the re presentation of the last submitted response. > The synchronization block delays processing until the previous request is completed Then it should be detected that it has been processed and skipped. > Use one of the "new" ranges, such as transformation, to process detection?

My direct intuition is that the best way is to turn sensitive blocks of code into atoms, and then the problem is to render the correct response

What should I do?

Solution

This is the simplest way to implement it in a general way If you happen to use < F: Ajax > specifically, you can use JSF ajax. Addonevent() executes the job in a generic manner Another JavaScript approach is to create a "load" override that prevents the UI from interacting with the underlying page This is basically absolutely positioned < div > it spans the entire viewport and has some opacity (transparency) You can show it when you submit and hide it on the render The keyword of this technology is "modal dialog" The UI - oriented JSF component library has at least such components For example Primefaces and < p: dialog modal = "true" > internal < p: ajaxstatus > or < p: blockui >

The only drawback is that if the client disables JS or does not use it, it will not work, so it will not prevent HTTP clients from double submitting

This is also called "synchronizer token pattern" and has been requested by spec issue 559. At present, this is a ticket for 2.2, but there seems to be no activity The detection and blocking part is technically easy to implement, but if you want the end user to finally retrieve the response generated by the initial request, the synchronous response processing part is not easy to implement Asynchronous response processing is easy: simply do not specify any components to update, that is, empty the collection returned by partialviewcontext#getrenderids() After all, this is more powerful than using JS to disable buttons or block the UI

As far as I know, seam 2 is the only one who provides reusable JSF components for < s: token > However, I must admit that this is an interesting idea for a new omnifaces component Maybe I'll see it myself

This is generally not easy to implement, which will require changing all operation methods to check whether the job has been completed If webapp runs on multiple servers, it won't work The synchronizer token is easier because it will execute before calling the action method Synchronizer tokens are also cheaper because you won't encounter multiple requests in the queue that can only consume threads / resources

This problem cannot be solved by managing bean scopes Managed bean scopes are used for different purposes: the lifecycle of the bean instance