What about (i)frames with pages being loaded in every one of them at the same time?
Frank On Jan 4, 2008 7:57 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > To me it seems like it would be an unusual situation for two threads to > access the session at the same time. Under what circumstances does this > happen? > > -----Original Message----- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 03, 2008 10:15 PM > To: users@wicket.apache.org > Subject: Re: Wicket Session and threading > > You're right, we should mention this in WIA. Would you mind leaving a > comment on the author forum? > http://www.manning-sandbox.com/forum.jspa?forumID=328 > > Cheers, > > Eelco > > On Jan 3, 2008 11:10 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > > > > Eelco Hillenius wrote: > > >> Am I right in concluding that I must make my wicket session > thread-safe? > > >> > > >> That is, if I want to store an "int" value in the session, I should > use > > >> a volatile or AtomicInteger? > > > > > > Yes. We try our best to make pages/ components as thread safe as > > > possible, but making the session thread safe would impose a too large > > > performance penalty. > > > > > >> Is there anywhere a small piece on how to deal with threading within > > >> Wicket (i.e., what is/is not synchronized in a request/response > > >> roundtrip?). I did some quick searching in the mailing list archives > and > > >> google, but could not find anything related to version 1.3. > > > > > > Pages are synced on pagemaps, which basically relates to browser > > > windows. RequestCycles are separate instances which are not reused, so > > > no sync needed there. Sessions are not synced so you need to sync > > > manually. Though in practice this wouldn't give much trouble to start > > > with. Applications are shared an not synced. > > > > > > Eelco > > > > Thanks for the answer. :-) > > > > Before really thinking about it I kind of implicitly assumed that > > session access was synced. It hasn't really gone wrong yet either, but > > that's probably because of the use of ThreadLocal which acts as a memory > > barrier (for session/application) and the fact that it's very hard to > > get two threads to interleave within one session unless you start having > > a fit on the mouse (or use lots of autoupdating ajaxy stuff). > > > > It could be (very) useful to have this info in the Wicket in Action book > > though. For example in listing 2.1 there is a Session object with a > > get/setUser, but it is completely unsynchronized; similarly, there is no > > synchronization at all on the Cheesr session. Again the visibility seems > > to be ensured by the fact that the session is set in a thread local, but > > the code somehow seems to suggest (to me anyway) that no synchronization > > is necessary... > > > > There are some comments on multithreadedness and threads (2.3; but in > > the context of detaching, not thread-safety, and 4.1.1 in the context of > > the Application object). However it also says (in 4.1.1) that all is > > safe if the Application only has read-only properties, however, in the > > CheesrApplication the list of cheeses is not final. This must mean that > > Wicket does ensure visibility (or else it's a bug ;-)), but that is not > > trivial and should probably be mentioned. > > > > Regards, > > Sebastiaan > > > > --------------------------------------------------------------------- > 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] > >
