Right... I think I'd just invert that, so that the "page" asked for the stateful data when needed.
- Brill Pappin -----Original Message----- From: Michael Allan [mailto:[EMAIL PROTECTED] Sent: Sunday, May 18, 2008 9:41 PM To: users@wicket.apache.org Subject: Re: Thread safety for components Brill Pappin wrote: > > ... So non-Wicket threads cannot generally access pages, > > components, models, and so forth - not safely. True? > > > I was trying to think of a use-case for that problem... Do you have a > specific use-case or is that just a potential issue you can think of? I'm thinking generally of state changes that occur in separate processes, changes that need to be presented in Web views. Specifically, I have a Web page that shows recent user activity, in a list view, where each element is a user activity event. Not all of my users are Web users, so the underlying list model is receiving events from other processes (mailer daemon, and so forth). Johan Compagner wrote: > Accessing pages in other threads then the request thread is very bad idea. > Because http session object shouldnt be touched between requests, you > have no idea what the container does with your page/session. Store it > on disc, replicate it to other nodes. Of course, now I understand... I was forgetting that instances of these things - pages, components and models - are apt to be serialized out of memory. Non-Wicket threads can't even hold a reference to them. So there's no point in exposing the page lock for other threads (as I suggested). > If you want to do stuff in background threads then let page/request > threads poll them if they are finished. Then the underlying list model (in my example, above) does not belong in the page; instead it belongs in the Application instance. There it can safely register with other threads, and receive events from them, because the app will never be serialized out of memory. And the list view (in the page) can hook up with the model (in the app), at request time, with appropriate synchronization - polling it, as you say. My only other question, then, is the app life cycle. (This article doesn't really answer my Q: http://cwiki.apache.org/WICKET/lifecycle-of-a-wicket-application.html In a clustered environment, are there multiple instances of the app? Might the page (the one with the list view, for example) find itself connecting to a different instance of the app, a different instance of the list model, from request to request? In a non-clustered environment, can I safely assume a single instance of the app, at any given time? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
