yes in a clustered environment you have multiply instances of the Application because there are more instances of the WicketServlet. And Application/Servlet context stuff are not replicated
johan On Mon, May 19, 2008 at 3:41 AM, Michael Allan <[EMAIL PROTECTED]> wrote: > 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] > >
