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]
