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.
We're talking about Page instances here, not the page class. Hence, the other 1000 users do not have to wait, as they have their own instances.
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.
A page does not span multiple sessions. A page is a session-specific object. In fact it is the top level session object for Wicket. Pages are stored in the session, and with it all the nested components and contained models.
Generally, a request is handled in two parts: 1. the handling part, e.g. a link clicked or form submit; 2. the rendering part.
These two parts can interfere and thus should be synchronized.
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.
No, we just have to synchronize the right parts.
Eelco
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
------------------------------------------------------- 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
