Brill Pappin wrote: > Right... I think I'd just invert that, so that the "page" asked for the > stateful data when needed.
Yes, that's the only way. The page can easily store the state (and you might rather it did) but it has to be pulled in, not pushed. The general rule is: no external thread can hold a reference to a Wicket model or view, because the model or view is apt, at any moment, to be serialized out of memory. (Restrictions like this must be obvious to a Web developer, but they're counter-intuitive to an old Swing hand.) Similar restrictions apply to the Session (as James was cautioning), because it too is serialized. Furthermore, the Session is not synchronized by the request thread. So code your Session subclass with thread safety in mind. Also code the Application with thread safety in mind. The Application is never serialized, however, so external threads can hold a live reference to it. Finally, clustering affects the environment (including the Application) that pages and components can expect when they pull state. (But maybe this is obvious.) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
