is not thread safe.. Same for shared resources those 2 can be hit by
placing a barrier. See Session.getPage() there there is code that
> 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
> <
jonathan.locke@...> 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:
users-unsubscribe@...
>>> For additional commands, e-mail:
users-help@...
>>>
>>>
>>>
>>
>> --
>> 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:
users-unsubscribe@...
>> For additional commands, e-mail:
users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
>