Hi Kristjan,
I think your mail is interesting but tend to agree with the other
posters who say this is not a Tapestry issue per se. I do not know of
any framework that queues up requests from a particular session to
ensure they are not executed in parallel. This would seem to be a bad
idea in principle.
Given that read/writes to the session itself are not synchronised,
it is
always possible for multiple request threads to get invalid state from
the session.
A potentially valid point is that the Tapestry model makes this
'worse'
by automatically reflecting the session at the start of processing and
only writing it back at the end (assuming this is what it does -- can
anyone confirm?). In a lower-level framework like raw servlets you
could
potentially minimise the effect of this problem by re-reading the
session value before writing it back after a long running process, but
you'd still have to deal with the exception if it had changed
(assuming
your long running process made use of the old value somehow!). Even in
this extreme case you'd only be minimising the problem because another
thread could still read and update the session state while you are
doing
the same at the end of your processing.
Perhaps there is already a standard pattern in Tapestry to avoid
multiple submits of a form? Although this would not affect your test
as
you have multiple browser windows.
Hope this makes sense,
Alfie.
-----Original Message-----
From: kristjankelt [mailto:kristjank...@hotmail.com]
Sent: 14 July 2009 11:11
To: users@tapestry.apache.org
Subject: Re: T5 Page field persistance and multithread problems
Hi,
Peter Stavrinides wrote:
Kristjan, as Nille has explained to you that is simply not the case,
what
is happening is multiple requests are being generated when the submit
button is clicked more than once, each of these Requests spawns a new
thread, and triggers the events that modify the affected values
accordingly.
Persisted objects scoped to 'session' are essentially just objects
placed
in the HttpSession, which is perfectly thread safe to do, so what
thread
problems are you referring to?
Multiple threads (initiated by multiple requests) accessing the same
data is
definitelly thread issue - it does not go away when you say that
this is
multiple request issue instead and everyone else is having the same
problem.
Of course this problem is caused by multiple requests that are allowed
to
run in paralel when they should wait in the queue instead but stating
this
does not make the code thread safe.
And of course this is really simple example that does not involve any
data
sent by the client - that would introduce more problems.
Peter Stavrinides wrote:
every page instance would have it's own *copy* of the data
Although a page object itself is pooled, and a clean copy is served
when
its requested. That does not mean that it contains copies of state
objects
/ data, if you peek inside the users HttpSession you will find only a
single SSO (or persistent field for that matter) of any session
scoped
objects. So far as I understand there are no 'copies' of these
objects
or
any other session data floating around, any persistent object in your
page
would simply be a 'reference' to those in the HttpSession.
Let say that I have new request. What happens now is that page is
taken
from
the pool and is initiated.
During that variable is read from the session and reference of the
page
object private variable is set to that variable.
Let assume that there was object Integer(1) in the session. Now both,
session and page object private variable are referencing to the same
object.
Let's name this variable a counter.
Let say that in the page event method (like in my example) I want to
increment the counter. For that I read the object Integer(1) int
(primitive)
value (or this is done by compiler using autoboxing), add one to it
and
create new object Integer(2) and set page private variable reference
to
new
object (Object(2)) (this happens because Integer is immutable and I
can
not
change it's innerstate).
From this moment, page and session will have different copies (and it
will
stay so until session reference is overridden at the end of page
processing).
When different thread is reading from the session then it will still
see
the
reference to Integer(1) and it's corrensponding page object private
variable
reference is set to Integer(1).
Now this example involved only one variable and this was immutable
(you
can
not change it's innerstate). Having multiple variables or immutable
variables (like entity beans) will introduce more problems.
Regards,
Kristjan Kelt
--
View this message in context:
http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems
-tp24468298p24476799.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
