Brill Pappin wrote:
> Right... I think I'd just invert that, so that the "page" asked for the
> stateful data when needed.
Yes, that's the only way. The page can easily store the state (and
you might rather it did) but it has to be pulled in, not pushed. The
general rule is: no external thread c
Right... I think I'd just invert that, so that the "page" asked for the
stateful data when needed.
- Brill Pappin
-Original Message-
From: Michael Allan [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 18, 2008 9:41 PM
To: users@wicket.apache.org
Subject: Re: Thread safety
Johan Compagner wrote:
> yes in a clustered environment you have multiply instances of the
> Application
> because there are more instances of the WicketServlet.
> And Application/Servlet context stuff are not replicated
Thanks Johan, I've documented Wicket's thread safety (as I understand
it) usi
yes in a clustered environment you have multiply instances of the
Application
because there are more instances of the WicketServlet.
And Application/Servlet context stuff are not replicated
johan
On Mon, May 19, 2008 at 3:41 AM, Michael Allan <[EMAIL PROTECTED]> wrote:
> Brill Pappin wrote:
> >
Brill Pappin wrote:
> I didn't know people were even following it :)
Small town, :) I'm working on something similar.
> I can tell you now that I only *wish* we had used something like Wicket for
> LobbyThem... Ruby on Rails was the biggest mistake we made as I can attest
> to 8 months after th
Brill Pappin wrote:
> > ... So non-Wicket threads cannot generally access pages,
> > components, models, and so forth - not safely. True?
> >
> I was trying to think of a use-case for that problem... Do you have a
> specific use-case or is that just a potential issue you can think of?
I'm think
It may even re-use the actual session object instance for another
person's session (by filling it with their stuff).
On Sun, May 18, 2008 at 9:12 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Accessing pages in other threads then the request thread is very bad idea.
> Because http session objec
Accessing pages in other threads then the request thread is very bad idea.
Because http session object shouldnt be touched between requests, you
have no idea what the container does with your page/session. Store it
on disc, replicate it to other nodes.
If you want to do stuff in background threads
: Thread safety for components
[...]
One possible problem - not affecting me yet, but just to be clear - no
access to the page lock (no official API) is provided for non-Wicket
threads. So non-Wicket threads cannot generally access pages, components,
models, and so forth - not safely. True?
When the
sed Wicket (or even plain old PHP)!
- Brill
-Original Message-
From: Michael Allan [mailto:[EMAIL PROTECTED]
Sent: Friday, May 16, 2008 11:33 PM
To: users@wicket.apache.org
Subject: Re: Thread safety for components
Brill Pappin wrote:
> Does that mean that under heavy load, hitting t
it yet to say that's a bad thing
:)
I'm looking forward to really getting into it!
- Brill
-Original Message-
From: Jonathan Locke [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 17, 2008 1:56 AM
To: users@wicket.apache.org
Subject: RE: Thread safety for components
I wouldn&#
Jonathan Locke wrote:
> ... the overall design is single-threaded, meaning you should not
> need to provide synchronization ... Is there some specific problem
> you have run into?
No, nothing specific yet - just a general foreboding of future
problems - having been bitten, before.
Johan Compagne
Brill Pappin wrote:
> Does that mean that under heavy load, hitting the index page for instance, I
> can expect clients to block as each request is processed?
Let me guess... The answer is no? Each session will have its own
instance of the index page. Threads of other sessions (other users)
will
to:[EMAIL PROTECTED]
> Sent: Saturday, May 17, 2008 1:03 AM
> To: users@wicket.apache.org
> Subject: Re: Thread safety for components
>
> On Fri, May 16, 2008 at 7:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
>> Does that mean that under heavy load, hitting the inde
appin
-Original Message-
From: Eelco Hillenius [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 17, 2008 1:03 AM
To: users@wicket.apache.org
Subject: Re: Thread safety for components
On Fri, May 16, 2008 at 7:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
> Does that mean that un
On Fri, May 16, 2008 at 7:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
> Does that mean that under heavy load, hitting the index page for instance, I
> can expect clients to block as each request is processed?
Yes, requests to pages/ components that belong to the same pagemap in
a session are ha
, 2008 2:53 AM
To: users@wicket.apache.org
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
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
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 t
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
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 p
21 matches
Mail list logo
