Re: [Wicket-develop] HttpRequestCycle.handleRender() fix for a page rendering at the same time.

[Gili]

Johan,

Thank you for clearing this up. I understand now.

Gili

--Original Message Text---
From: Johan Compagner
Date: Thu, 06 Jan 2005 18:02:25 +0100

Page object doesn't span acros any sessions!!!!
Page object is just a component that is session bound.
synchronizing on a session can scale a bit less then a page object
Because it can be that (when working in frames) one client (session) is zending 2 request but then
for 2 pages/components.. Those are also synchronized with the current way
If we could rewrite it that it syncs on the Page object then it would only block on rendering the same page
And that should be done anyway. One page can or may never be rendered more then once at the same time.

johan


Gili wrote: On Thu, 06 Jan 2005 10:52:44 +0100, Johan Compagner wrote:

So in the end. We don't have to synchronize on the session i think. But
we should synchronize on the page object.
But that is a problem because callComponentListener is currently also
responseable for lookup the page which we would render.


This is the very thing I was warning about: we should not be
synchronizing over the Page because it'll kill the scalability of
Wicket. Synchronizing over the session is intuitive: the only should
only be viewing one page at a time but synchronizing over the page is a
horrible idea because it means that when one user renders the page the
other 1000 users hitting the webpage at that time cannot do the same.

If this is the current situation, we should rework the
rendering code to avoid having to do this and allow ourselves to
synchronize only over the session.

1> HttpRequestCycle.callComponentListener() This one call an interface
methods of components. If this changes
the component structure somehow. Then after this call in the
page.render() should use that specific set of components
that the page did have after the call to callComonentListener. But if a
second request does exactly the same thing and
again the page is modified. Then the page.render suddenly has different
components. Strange things can happen then
for example a component is in render fase but doesn't have a Page parent
object anymore.


This seems like a pretty straight-forward bug to me. When a
page renders, if any Page state needs to change, it should manipulate
session-specific objects, not Page which spans across multiple
sessions.

2> It is possible that 2 request uses the exact same MarkupStream
component of a container/panel.
first request makes a MarkupStream (instance1) then a second request
makes also a MarkupStream (instance2)
then instance1 is replaced by instance2 and if then the first request
takes the markupstream (see Container.findMarkupStream())
but it uses the instance2 markupstream then. Not the one he made
himself! And then the second request also uses
that markupstream. But then all strange things can happen because a
markupstream has a state (Current MarkupElement)


I think in this case we're supposed to be using two different
MarkupStream objects, one per session. We might want to consider
thread-local MarkupStream objects.

Gili