In 1.5 I think it is improved because now the synchronization is on page
instance (version) not on pagemap. So it is more fine grained.

On Fri, Mar 18, 2011 at 6:07 PM, Martijn Dashorst <
[email protected]> wrote:

> On Fri, Mar 18, 2011 at 6:01 PM, Johan Compagner <[email protected]>
> wrote:
> > besides that we must make sure that the object hiearchy and so on is not
> suddenly in a wrong state.
>
> That is the idea: the object hierarchy should not be put into the page
> store—essentially throwing away any changes made during that partially
> processed request.
>
> > And there are cases that request 1 is still way more important then
> request 2 and request 2 may never just kill 1. (Request 2 is just a
> background polling thread of are there any changes)
>
> Request 2 will only complete when request 1 is finished, so much for
> polling :). In most if not all cases where request1 takes longer than
> 10 seconds, it should be done in a background thread. Unfortunately
> JEE does not provide a good way to facilitate that.
>

Actually it does - Servlet 3's AsyncContext (aka Jetty Continuations) but I
think this way it will be very hard for the application programmer.
Context can switch at any time and someone has to take care to synchronize
access to page/session/application structures.
Currently requests are serialized (executed one after another) and each
request depends on the fact that when has fired the page state was X.
There is even Wicket.ChannelManager in wicket-ajax.js who cares to queue the
requests as they arrived.

>
> A bigger issue is that when request 1 has finished processing the
> listener phase, but rendering the response takes too long. What should
> happen in that instance?
>
> How do you imagine to control one thread from another ?
Currently the web container worker thread does the whole processing. To be
able to interrupt the hanging thread we will need to start our own threads
and manage them.


> Martijn
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Reply via email to