Thread safety for components

[Brill Pappin]

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:mike@...]
Sent: Sunday, May 18, 2008 9:41 PM
To: users@...
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: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael Allan]

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: users-unsubscribe@...
For additional commands, e-mail: users-help@...