Like i said: details i am blissfully unaware of :) Thanks for clearing that up Johan.
Maurice On Fri, May 16, 2008 at 8:53 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > 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/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] >> >> > > --------------------------------------------------------------------- > 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]
