Hi, sorry the delay - sure I can share what I have done. And please send any comments freely, if you can see any issues in the way I made it - I'm not filter expert, for example mutex may be used too widely etc.. 

We have filter base class that all filters extends... but I think you get the idea from this method called for each filter:

...
private static final Object mutex = new Object();
...

public void doMainProcessing(ServletRequest request, ServletResponse response, FilterChain chain) {

    HttpServletRequest httpReq = (HttpServletRequest) request;
    HttpServletResponse httpResp = (HttpServletResponse) response;
    String uri = httpReq.getRequestURI();
    HttpSession mySession = ((HttpServletRequest) request).getSession(false);

    synchronized (mutex) {
      Boolean requestInProgess = null;
      if (mySession != null) {
        requestInProgess = (Boolean) mySession .getAttribute("SEMAPHORE_REQUEST_IN_PROGRESS");
        if (requestInProgess != null) {
          if (requestInProgess.booleanValue()) {
            String userAgent = httpReq.getHeader("User-Agent").toLowerCase();
            /* IE */
            if (null != userAgent && userAgent.indexOf("msie") > -1) {
              httpResp.setStatus(HttpServletResponse.SC_NO_CONTENT);
            } else {
              /* Other browsers */
              httpResp.setHeader("Refresh","3; URL="" mySession.getAttribute("SEMAPHORE_REQUEST_URI"));
            }
            return;
          }
        }
        mySession.setAttribute("SEMAPHORE_REQUEST_IN_PROGRESS", Boolean.TRUE);
        mySession.setAttribute("SEMAPHORE_REQUEST_URI", uri);
      }
    }
    try {
      chain.doFilter(request, httpResp);
    } catch (Exception ex) {
      throw new RuntimeException(ex);
    } finally {
      synchronized (mutex) {
        try {
          HttpSession afterSession = ((HttpServletRequest) request).getSession(false);
          if (afterSession != null) {
            afterSession.setAttribute("SEMAPHORE_REQUEST_IN_PROGRESS", Boolean.FALSE);
          }
        } catch (Exception ex) {
          logger .fine("Session already terminated in DoubleClickFilter : "+ ex.getMessage());
        }
      }
    }
  }



On 11/22/05, Yee CN <[EMAIL PROTECTED]> wrote:

Hi,

 

I am facing the same problem, and am interested to implement your solution. Can you please share your code?

 

Many thanks

 

Yee

 


From: Vesa Lindfors [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 9 November 2005 4:47 PM
To: MyFaces Discussion; [EMAIL PROTECTED]
Subject: Re: Handling multiple concurrent submits

 

I solved the doubleclick issues with servlet-filter:
Filter sets the session-wide flag and requested URL at the begin of each request and clears them at the end.
If second request is coming during the previous one is in execution, the filter is doing redirect with few seconds delay to originally requested page (in case not IE) or HttpServletResponse.SC_NO_CONTENT (in case of IE). I tried some other headers but didn't succeed, so thats why using redirect like httpResp.setHeader( "Refresh", "3; URL="" mySession.getAttribute("SEMAPHORE_REQUESTED_URI"));
I'm not sure if this is best approach, but it has worked for us.
--- VLi ---

On 11/9/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:

You'll need to synchronize access to your session objects - there
really is not much way around it.

Alternative is to have everything client side, then you don't have any
problems on the server.

Except the performance, of course ;)

regards,

Martin

On 11/9/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've noticed that if I click multiple times on a component that does a
> submit then quite often I get an exception generated in the server.
>
> The most obvious case for me is a table with a sortable header; if I
> pretend to be impatient and click several times on the sort header then
> usually I end up with an exception page.
>
> I believe the cause is that the browser has submitted several concurrent
> post requests to the server; multiple threads within the server then try
> to run the view at the same time, and as view components are not
> threadsafe all sorts of nasty side-effects occur. An example of a
> non-threadsafe component is a UIData with session scope; it's got only
> one rowIndex, so multiple threads trying to iterate over the rows in the
> table is bound to result in something unpleasant.
>
> How do people handle this? I can't force my users to go on a training
> course about waiting for a page to complete before clicking again. And I
> can't live with exception pages being rendered to them if they click too
> quick.
>
> Thanks,
>
> Simon
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

 


Reply via email to