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 can
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:
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) using
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 for components
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
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 object
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 thinking
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 the
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
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 Compagner
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't spend too much time
(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 the index page
: 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
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
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
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
, 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
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
-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 under heavy load, hitting
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 index page for
instance, I can expect clients to block as each request is processed?
Yes
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
21 matches
Mail list logo
