Re: Thread safety of various Wicket classes?
I'm trying to understand how Wicket deals with thread-safety. From Wicket in Action by Martijn Dashorst Eelco Hillenius You never have to worry about thread-safety as long as you keep two things in mind: * Never share component object instances, models, and behaviors between pages that are in several page maps. ... * Application objects, session objects, and session stores aren't thread-safe I thought @Jochen Mader's explanation was eloquent, No state = threadsafe but I'm looking for some clarification. Latter Eelco writes about behaviors, All the methods in [the IBehavior interface] except isTemporary share a comon feature: they have a Component argument. This way, behaviors can be stateless... Given that behaviors are stateless, why is it discouraged to share them? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Thread-safety-of-various-Wicket-classes-tp4652977p4661123.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Thread safety of various Wicket classes?
Given that behaviors are stateless, why is it discouraged to share them? Behaviors can be stateless, but they don't need to be. You can share them between components in the same page. But sharing behaviors (or models) between pages is not possible, because each page is serialized separately. Sven On 08/28/2013 09:47 PM, sc_wicket wrote: I'm trying to understand how Wicket deals with thread-safety. From Wicket in Action by Martijn Dashorst Eelco Hillenius You never have to worry about thread-safety as long as you keep two things in mind: * Never share component object instances, models, and behaviors between pages that are in several page maps. ... * Application objects, session objects, and session stores aren't thread-safe I thought @Jochen Mader's explanation was eloquent, No state = threadsafe but I'm looking for some clarification. Latter Eelco writes about behaviors, All the methods in [the IBehavior interface] except isTemporary share a comon feature: they have a Component argument. This way, behaviors can be stateless... Given that behaviors are stateless, why is it discouraged to share them? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Thread-safety-of-various-Wicket-classes-tp4652977p4661123.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Thread safety of various Wicket classes?
Thanks. Makes sense On Wed, Aug 28, 2013 at 3:10 PM, Sven Meier [via Apache Wicket] ml-node+s1842946n4661124...@n4.nabble.com wrote: Given that behaviors are stateless, why is it discouraged to share them? Behaviors can be stateless, but they don't need to be. You can share them between components in the same page. But sharing behaviors (or models) between pages is not possible, because each page is serialized separately. Sven On 08/28/2013 09:47 PM, sc_wicket wrote: I'm trying to understand how Wicket deals with thread-safety. From Wicket in Action by Martijn Dashorst Eelco Hillenius You never have to worry about thread-safety as long as you keep two things in mind: * Never share component object instances, models, and behaviors between pages that are in several page maps. ... * Application objects, session objects, and session stores aren't thread-safe I thought @Jochen Mader's explanation was eloquent, No state = threadsafe but I'm looking for some clarification. Latter Eelco writes about behaviors, All the methods in [the IBehavior interface] except isTemporary share a comon feature: they have a Component argument. This way, behaviors can be stateless... Given that behaviors are stateless, why is it discouraged to share them? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Thread-safety-of-various-Wicket-classes-tp4652977p4661123.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org ___ If you reply to this email, your message will be added to the discussion below: http://apache-wicket.1842946.n4.nabble.com/Thread-safety-of-various-Wicket-classes-tp4652977p4661124.html To unsubscribe from Thread safety of various Wicket classes?, visit http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4652977code=c3BlbmNlcmRjYXJsc29uQGdtYWlsLmNvbXw0NjUyOTc3fDE4ODczMjMwMTk= -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Thread-safety-of-various-Wicket-classes-tp4652977p4661125.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Thread safety of various Wicket classes?
First of all: You shouldn't start optimizing without having an actual problem. I don't see a real benefit in sharing a validator between several components. ON THE OTHER SIDE There shouldn't be a problem using Validators across several component instances as I am not aware of a single stateful validator. No state = threadsafe (wack me on the head if I'm wrong) On Wed, Oct 17, 2012 at 7:39 AM, Ondrej Zizka ozi...@redhat.com wrote: Ok, thanks. So I guess I should assume all classes unsafe, even if I check the code - since that can change. Maybe it would be worth considering committing to keeping certain class groups thread-safe, like validators. Just an idea. Ondra On Tue, 2012-10-16 at 09:17 +0200, Martin Grigorov wrote: Hi, Access to pages in Wicket is synchronized, i.e. only one thread can manipulate the page. So, if you use non-static member fields then there is no problem. If you use static ones then you need to verify that they are thread safe and can be used in such a way. On Mon, Oct 15, 2012 at 5:07 AM, Ondrej Zizka ozi...@redhat.com wrote: Hi all, for repeaters, I didn't like adding a new validators, attribute modifiers etc for each single row. So I create just one and pass the reference. 1) Is it ok to have just one at component instance level? 2) Is it ok to make it a static final instance at app level? And about thread safety in general - is there some info about Wicket's classes, with some Do's and Don't's? Since Wicket gives a lot of freedom regarding hacking on it, I guess users should be aware. Thanks, Ondra - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Thread safety of various Wicket classes?
Hi, Access to pages in Wicket is synchronized, i.e. only one thread can manipulate the page. So, if you use non-static member fields then there is no problem. If you use static ones then you need to verify that they are thread safe and can be used in such a way. On Mon, Oct 15, 2012 at 5:07 AM, Ondrej Zizka ozi...@redhat.com wrote: Hi all, for repeaters, I didn't like adding a new validators, attribute modifiers etc for each single row. So I create just one and pass the reference. 1) Is it ok to have just one at component instance level? 2) Is it ok to make it a static final instance at app level? And about thread safety in general - is there some info about Wicket's classes, with some Do's and Don't's? Since Wicket gives a lot of freedom regarding hacking on it, I guess users should be aware. Thanks, Ondra -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Thread safety of various Wicket classes?
Ok, thanks. So I guess I should assume all classes unsafe, even if I check the code - since that can change. Maybe it would be worth considering committing to keeping certain class groups thread-safe, like validators. Just an idea. Ondra On Tue, 2012-10-16 at 09:17 +0200, Martin Grigorov wrote: Hi, Access to pages in Wicket is synchronized, i.e. only one thread can manipulate the page. So, if you use non-static member fields then there is no problem. If you use static ones then you need to verify that they are thread safe and can be used in such a way. On Mon, Oct 15, 2012 at 5:07 AM, Ondrej Zizka ozi...@redhat.com wrote: Hi all, for repeaters, I didn't like adding a new validators, attribute modifiers etc for each single row. So I create just one and pass the reference. 1) Is it ok to have just one at component instance level? 2) Is it ok to make it a static final instance at app level? And about thread safety in general - is there some info about Wicket's classes, with some Do's and Don't's? Since Wicket gives a lot of freedom regarding hacking on it, I guess users should be aware. Thanks, Ondra
Thread safety of various Wicket classes?
Hi all, for repeaters, I didn't like adding a new validators, attribute modifiers etc for each single row. So I create just one and pass the reference. 1) Is it ok to have just one at component instance level? 2) Is it ok to make it a static final instance at app level? And about thread safety in general - is there some info about Wicket's classes, with some Do's and Don't's? Since Wicket gives a lot of freedom regarding hacking on it, I guess users should be aware. Thanks, Ondra
