From
http://tapestry.apache.org/tapestry5/tapestry-core/guide/lifecycle.html:
"This is how Tapestry keeps you from worrying about multi-threading
issues ... the objects involved in any request are reserved to just that
request (and just that thread)."
So I think you are right. Let me amend my statement by saying that an
instance of a page class will be reused. Naturally this would suggest
that stale values from other requests (and therefore other clients)
would show up on the pages of other users (and indeed they do, without
proper care). So @ApplicationState must remind the IoC container that
whenever a page is attached to a request, it must populate the state
objects according to the attached session.
Thanks :-)
Richard Kirby wrote:
Hi Chris,
You wrote:
manager to retrieve page members marked as state objects with the
@ApplicationState annotation. Why? Because an instance of a page
class may be accessed simultaneously by many different requests at
the same time. In reality the annotation is just an indicator that a
page
I don't think this is actually correct. Definitely in Tap4 and a quick
reading of the lifecycle page for Tap5 suggests that an instance of a
page is locked to a request for the duration of that request. This
also means it is on a single thread (ie the thread handling the
request) for the duration of the request.
This is why pages are pooled - because you may need more than one
instance of a page to handle simultaneous requests.
That is my understanding anyway
Richard
---------------------------------------------------------------------
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]
