best practice for handling double-click during a long-runnin

[eghchang]

hello,

is there a suggested methodology for handling a double-click during a long-running conversation? the default behavior during a double-click is the following message:

The conversation ended, timed out or was processing another request

is there a way to ignore subsequent requests until the first is processed? we're okay with throwing away any information that might be in subsequent requests. we're aware that there are javascript client-side methods, but we'd prefer something more robust on the server side.

btw, we're using Seam 1.2.1.GA.

thank you,
Eric

[norman.richards]

Seam serializes requests in a conversation. Are you actually seeing multiple concurrent requests, or are you just seeing the annoying message?

[amitev]

There actually no concurent requests but the action method is called twice. This may cause double insert into database.

[eghchang]

thanks norman and amitev for your replies.

norman, when double-clicking i can see (using firebug) that two requests are being sent to the application server before any response is received. furthermore, i don't see any errors in the server log that would suggest a double insert/optimistic locking. yet i still get the same "the conversation ended, timed out, or was processing another request" error message. in this particular case, i'm posting back to the same page in the context of a long-running conversation (simple "save" functonality that does not navigate away).

i had been setting no-cache http headers to force refresh of pages (via a JSF phase listener), but i disabled these headers thinking that perhaps they are complicating things. the one other thing that's odd is that i can see that even with single-click requests, action methods are being called twice. however, this has been the case for a while and we haven't had any other problems (e.g. optimistic locking) as a result. we are using keep-alive connections, but i wouldn't think that should have any impact.

just as a sanity check, if i am seeing multiple requests from the browser before any response, would you expect the error message i'm seeing?

[eghchang]

one more thing ... while i do see multiple requests from the browser, i only see one request (well actually, set of requests, but this is "normal") on the server. in other words, the server looks the same whether i single-click or double-click.

thanks-eric

[eghchang]

i did a little debugging and am finding that in org.jboss.seam.core.Manager.restoreAndLockConversation() the call to ConversationEntry.lock() is returning false because Manager.instance().getConcurrentRequestTimeout() (which is set to 1000 ms) has been exceeded.

it looks like our request processing is taking more than 1000ms to complete, so i guess i need to increase the value of org.jboss.seam.core.manager.concurrentRequestTimeout?

[ohad]

You can increase concurrent-request-timeout to 1500ms in the component.xml
file..

<core:manager concurrent-request-timeout="1500"
...

My team is looking for a better solution.

We will let you know..

[eghchang]

thanks, increasing the timeout does help address our double-click within the same long-running conversation problem.

i realize that we still need to figure out how to handle a double-click when the action expression called ends the long-running conversation (via @End) ... in this case, the second request waits for the first request to complete only to find the conversation has already ended.

at this point, i'm leaning towards implementing a filter/JSF phase listener that detects requests on the same conversation occurring within some time configurable time window (e.g. 500ms) and throws out later requests falling within this time window.