wicket synchronizes on the session. So only one request is processed at a time, (except for resources like images etc) So even ajax requests are synchronized.
There might be some more details i am not aware of but this is in a nutshell our synchronization. Maurice On Fri, May 16, 2008 at 4:33 AM, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > > I'm not sure precisely what the current synchronization implementation is > and there may be some edge cases that are not perfect, but the overall > design is single-threaded, meaning you should not need to provide > synchronization. Some requests, like image resources would potentially be > handled in parallel, but anything that calls user code ought to be > synchronized by Wicket so you don't have to think about it. I suppose there > might be complications with asynchronous Ajax events, but I would expect > these cases are already handled. Is there some specific problem you have > run into? > > > Michael Allan wrote: >> >> 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] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Thread-safety-for-components-tp17265324p17266550.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
