I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion "Wicket Session and threading":
http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: > Yes. We try our best to make pages/ components as thread safe as > possible... > > > 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. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
