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
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
