Expected date for JSF RI 1.2?

Question

Hi,
I'm wondering when the implementation of the JSF 1.2 specfication will be available. It's the duplicate button press problem I'm concerned about. It has been logged as issue 31 with the JSF spec https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=31
Depending on the date we can wait for the solution in JSF RI 1.2 or we will have to implement ourselves a solution that ideally streams the rendered output from the first request to the last request received.
Obviously I'd rather wait. :-)
Sincerely,
Joost de Vries

Answer 1

I've implemented this in the past in an application although that application was not on top of jsf.
What we did was: before processing a request it is checked wether there is already a request processing for this client.
If not: flag that this request is going to process. After request processing, before streaming the response to the client check wether there is a new response writer for this client and stream the response to this writer.
If there is: set this response writer as the new response writer for this client and abandon further request processing or rendering for this client.
We buffered rendering to make the final streaming to the client 'more atomic'. This has a memory penalty of course.
This does solve single-client concurrency for the non-rendering part of the processing lifecycle. Once streaming to the client of the first thread has started though I see no way of handling this gracefully unless you have buffered the response streamed by the first thread: in that case you can send this buffered response to the client.
I expect the difficulty to be in finding the right hooks in the JSF framework for 1 checking wether there is already a thread processing for this client, 2 in supplying the rendering phase the right response writer and 3 in finishing the later concurrent thread without having it render itself.
Come to think of it: nr 3 might mean that 'the' response must be streamed by the last entering thread. Especially since the previously entering thread probably hits an IOException since the browser closes the reading socket in favour of the later request.
If you decide to implement this: email me at sultan_boabdil x hotmail y com (substitute x and y with the obvious signs to make it and email address) so we can find out wether we can share resources.
Groeten uit Nederland,
Joost de Vries