Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed?
Have anyone tested this on a site with heavy traffic? - Brill -----Original Message----- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 2:53 AM To: [email protected] Subject: Re: Thread safety for components It is not sync around session, for one thing the wicket Sessio object is not thread safe.. Same for shared resources those 2 can be hit by multiply rerquest at once. Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait On 5/16/08, Maurice Marrink <[EMAIL PROTECTED]> wrote: > 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/th >>> read >>> >>> 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-tp17265324p1726655 >> 0.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] > > --------------------------------------------------------------------- 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]
