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
smime.p7s
Description: S/MIME Cryptographic Signature
