You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by kristjankelt <kr...@hotmail.com> on 2009/07/13 22:21:20 UTC
T5 Page field persistance and multithread problems
Hi,
After a little thinking about Tapestry persistence, I constructed a sample
that shows how Tapestry page field persistence handling is not thread safe.
This is a page class and it's template:
http://www.nabble.com/file/p24468298/NotSafe.java NotSafe.java
http://www.nabble.com/file/p24468298/NotSafe.tml NotSafe.tml
Now when you hit the "update" button more than once in IE (Firefox prevents
multiple requests, but remember that this is only client side security) you
will still see value incremented only by one. You will see also in the
console multiple outputs with the same value.
This is so because each request will get it's copy of the counter at the
beginning of the request and will write it back after it finishes
processing.
Alternative would be moving this code into "Setup Render" method and hitting
the refresh button many times - this will work also with Firefox.
I'm writing about this because Tapestry documentation creates sense of false
security because it states that Page classes could be written in not thread
safe manner (what is true when you do not have persistent fields) but this
statement does not hold in all the cases.
I played with the locks in the session and it kind of worked (you can make
another request to wait or raise a exception to indicate duplicate request).
When anyone has more ideas about this problem then I'm more than thankful to
hear about them.
Regards,
Kristjan Kelt
--
View this message in context: http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24468298.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by kristjankelt <kr...@hotmail.com>.
Hi,
Ok, here is a example with a immutable object.
http://www.nabble.com/file/p24485700/Person.java Person.java
http://www.nabble.com/file/p24485700/NotSafe2.java NotSafe2.java
http://www.nabble.com/file/p24485700/NotSafe2.tml NotSafe2.tml
You can test how many times you see SAME and how many times you see
DIFFERENT.
Regards,
Kristjan Kelt
--
View this message in context: http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24485700.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by Robert Zeigler <ro...@scazdl.org>.
Well, it /is/ the case that page fields and pages are thread-safe.
But persistent fields are accessing their data from the session, and
session-bound data is only thread-safe if you explicitly make it so.
You're right, though: the documentation should probably be more clear
in that regard, as you pointed out.
Robert
On Jul 13, 2009, at 7/133:21 PM , kristjankelt wrote:
>
> Hi,
>
> After a little thinking about Tapestry persistence, I constructed a
> sample
> that shows how Tapestry page field persistence handling is not
> thread safe.
>
> This is a page class and it's template:
>
> http://www.nabble.com/file/p24468298/NotSafe.java NotSafe.java
> http://www.nabble.com/file/p24468298/NotSafe.tml NotSafe.tml
>
> Now when you hit the "update" button more than once in IE (Firefox
> prevents
> multiple requests, but remember that this is only client side
> security) you
> will still see value incremented only by one. You will see also in the
> console multiple outputs with the same value.
>
> This is so because each request will get it's copy of the counter at
> the
> beginning of the request and will write it back after it finishes
> processing.
>
> Alternative would be moving this code into "Setup Render" method and
> hitting
> the refresh button many times - this will work also with Firefox.
>
> I'm writing about this because Tapestry documentation creates sense
> of false
> security because it states that Page classes could be written in not
> thread
> safe manner (what is true when you do not have persistent fields)
> but this
> statement does not hold in all the cases.
>
> I played with the locks in the session and it kind of worked (you
> can make
> another request to wait or raise a exception to indicate duplicate
> request).
>
> When anyone has more ideas about this problem then I'm more than
> thankful to
> hear about them.
>
> Regards,
> Kristjan Kelt
> --
> View this message in context: http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24468298.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by Robert Zeigler <ro...@scazdl.org>.
Alfie, actually, many people have done just that.
And for the record, Kristjan is right in that this is very much a
threading issue.
Multiple threads accessing the same data concurrently => potential
threading issues.
In the case of non-persisted field and values on a page, you don't
have threading issues because the data is unique to each request. But
the moment you introduce session-persisted data, you've moved beyond
that scope and you absolutely have to consider multi-threaded
effects. The problem is marginal for @Persisted fields; at least the
persisted-data is specified to a single page. But using session state
objects, the potential problem becomes worse. If you're using session
state objects, and you're not considering the impact of multiple
threads on your data, you're asking for trouble. That said, this
problem is certainly not unique to Tapestry; anytime the session is
invoked, you have potential threading issues.
Cheers,
Robert
On Jul 14, 2009, at 7/148:09 AM , Alfie Kirkpatrick wrote:
> 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:kristjankelt@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5 Page field persistance and multithread problems
Posted by Alfie Kirkpatrick <Al...@ioko.com>.
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:kristjankelt@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by Otho <ta...@googlemail.com>.
2009/7/14 Howard Lewis Ship <hl...@gmail.com>
> I am loathe to have the framework manage this automatically because it
> causes its own problems.
>
> For example, it is reasonable to process multiple Ajax requests in
> parallel if they only read data.
Exactly. Concurrent write access to data should be handled where it belongs
and that is definitely not the weblayer as such and I wouldn't even want the
webframework interfere with it. Doing things in a http-layer which naturally
belong to a persistence/transaction/business layer would be a quite dirty
hack in my opinion. There was a lot of research spent on making concurrent
writes "threadsafe" in databases. Transactions, optimistic and pessimistic
locking and isolation levels where developed for exactly that case. So there
is really no need to make a UI-Framework behave like a database with
ISOLATION_LEVEL_SERIALIZED.
Re: T5 Page field persistance and multithread problems
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Jul 14, 2009 at 3:10 AM, kristjankelt<kr...@hotmail.com> wrote:
>
> 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.
I suppose the framework could keep a Mutex keyed on session so that
multiple page or event requests could be serialized on the server.
I am loathe to have the framework manage this automatically because it
causes its own problems.
For example, it is reasonable to process multiple Ajax requests in
parallel if they only read data.
>>
>> 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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by kristjankelt <kr...@hotmail.com>.
Hi,
Otho wrote:
>
> Thatswhy you normally use a transactional storage for entity beans.
>
My mistake that I mentioned word "entity". Well, I actually meant any bean
as example of immutable object.
Because there may be cases when I want to hold persisting into database
until I have all the required data. For example adding a new order - I
collect all the order details and add the order only when all the data is
provided by the user and this may require multiple requests.
Otho wrote:
>
> Your case is working on the weaknesses of the http protocol which is
> inherently
> stateless.
>
I think that my case is working because no care has been taken to make this
code thread safe.
Regards,
Kristjan Kelt
--
View this message in context: http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24478142.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by Otho <ta...@googlemail.com>.
Thatswhy you normally use a transactional storage for entity beans. Your
case is working on the weaknesses of the http protocol which is inherently
stateless.
2009/7/14 kristjankelt <kr...@hotmail.com>
>
> 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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5 Page field persistance and multithread problems
Posted by kristjankelt <kr...@hotmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Page field persistance and multithread problems
Posted by Peter Stavrinides <P....@albourne.com>.
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?
>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.
Kind regards,
Peter
----- Original Message -----
From: "kristjankelt" <kr...@hotmail.com>
To: users@tapestry.apache.org
Sent: Tuesday, 14 July, 2009 11:14:20 GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: Re: T5 Page field persistance and multithread problems
Hi,
I think that this is definitelly thread issue because data is shared between
multiple threads. Even when every page instance would have it's own *copy*
of the data, it is still shared between multiple instances at the end.
Of cource yes - every page will run in it's own thread but this does not
erase thread problems.
Regards,
Kristjan Kelt
nille hammer wrote:
>
> Hi,
>
> This is NOT a thread issue, but behavoiour that one would expect with
> values persisted in the session. The requests coming all from within the
> same session store and fetch the (same) value in the sesion.
>
> Add this to the java file
> @PageAttached
> private void showPageInstance() {
> System.out.println(this);
> }
> You'll see that each request is handled by a different instance of the
> page therefore handled in a thread safe manner.
>
> The only problem observed here is the double submit problem. That is not a
> bug of Tapestry but must be handled by every webapp no matter what
> framework. Ways to do this are unique ids for forms or a state field.
>
> Regards, nillehammer
> ==
> http://www.winfonet.eu
>
> ----- original Nachricht --------
>
> Betreff: Re: T5 Page field persistance and multithread problems
> Gesendet: Di, 14. Jul 2009
> Von: Robert Zeigler<ro...@scazdl.org>
>
>> Well, it /is/ the case that page fields and pages are thread-safe.
>> But persistent fields are accessing their data from the session, and
>> session-bound data is only thread-safe if you explicitly make it so.
>> You're right, though: the documentation should probably be more clear
>> in that regard, as you pointed out.
>>
>> Robert
>>
>> On Jul 13, 2009, at 7/133:21 PM , kristjankelt wrote:
>>
>> >
>> > Hi,
>> >
>> > After a little thinking about Tapestry persistence, I constructed a
>> > sample
>> > that shows how Tapestry page field persistence handling is not
>> > thread safe.
>> >
>> > This is a page class and it's template:
>> >
>> > http://www.nabble.com/file/p24468298/NotSafe.java NotSafe.java
>> > http://www.nabble.com/file/p24468298/NotSafe.tml NotSafe.tml
>> >
>> > Now when you hit the "update" button more than once in IE (Firefox
>> > prevents
>> > multiple requests, but remember that this is only client side
>> > security) you
>> > will still see value incremented only by one. You will see also in the
>> > console multiple outputs with the same value.
>> >
>> > This is so because each request will get it's copy of the counter at
>> > the
>> > beginning of the request and will write it back after it finishes
>> > processing.
>> >
>> > Alternative would be moving this code into "Setup Render" method and
>> > hitting
>> > the refresh button many times - this will work also with Firefox.
>> >
>> > I'm writing about this because Tapestry documentation creates sense
>> > of false
>> > security because it states that Page classes could be written in not
>> > thread
>> > safe manner (what is true when you do not have persistent fields)
>> > but this
>> > statement does not hold in all the cases.
>> >
>> > I played with the locks in the session and it kind of worked (you
>> > can make
>> > another request to wait or raise a exception to indicate duplicate
>> > request).
>> >
>> > When anyone has more ideas about this problem then I'm more than
>> > thankful to
>> > hear about them.
>> >
>> > Regards,
>> > Kristjan Kelt
>> > --
>> > View this message in context:
>> http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp2
>> 4468298p24468298.html
>> > Sent from the Tapestry - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> --- original Nachricht Ende ----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24475427.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Re: T5 Page field persistance and multithread problems
Posted by kristjankelt <kr...@hotmail.com>.
Hi,
I think that this is definitelly thread issue because data is shared between
multiple threads. Even when every page instance would have it's own *copy*
of the data, it is still shared between multiple instances at the end.
Of cource yes - every page will run in it's own thread but this does not
erase thread problems.
Regards,
Kristjan Kelt
nille hammer wrote:
>
> Hi,
>
> This is NOT a thread issue, but behavoiour that one would expect with
> values persisted in the session. The requests coming all from within the
> same session store and fetch the (same) value in the sesion.
>
> Add this to the java file
> @PageAttached
> private void showPageInstance() {
> System.out.println(this);
> }
> You'll see that each request is handled by a different instance of the
> page therefore handled in a thread safe manner.
>
> The only problem observed here is the double submit problem. That is not a
> bug of Tapestry but must be handled by every webapp no matter what
> framework. Ways to do this are unique ids for forms or a state field.
>
> Regards, nillehammer
> ==
> http://www.winfonet.eu
>
> ----- original Nachricht --------
>
> Betreff: Re: T5 Page field persistance and multithread problems
> Gesendet: Di, 14. Jul 2009
> Von: Robert Zeigler<ro...@scazdl.org>
>
>> Well, it /is/ the case that page fields and pages are thread-safe.
>> But persistent fields are accessing their data from the session, and
>> session-bound data is only thread-safe if you explicitly make it so.
>> You're right, though: the documentation should probably be more clear
>> in that regard, as you pointed out.
>>
>> Robert
>>
>> On Jul 13, 2009, at 7/133:21 PM , kristjankelt wrote:
>>
>> >
>> > Hi,
>> >
>> > After a little thinking about Tapestry persistence, I constructed a
>> > sample
>> > that shows how Tapestry page field persistence handling is not
>> > thread safe.
>> >
>> > This is a page class and it's template:
>> >
>> > http://www.nabble.com/file/p24468298/NotSafe.java NotSafe.java
>> > http://www.nabble.com/file/p24468298/NotSafe.tml NotSafe.tml
>> >
>> > Now when you hit the "update" button more than once in IE (Firefox
>> > prevents
>> > multiple requests, but remember that this is only client side
>> > security) you
>> > will still see value incremented only by one. You will see also in the
>> > console multiple outputs with the same value.
>> >
>> > This is so because each request will get it's copy of the counter at
>> > the
>> > beginning of the request and will write it back after it finishes
>> > processing.
>> >
>> > Alternative would be moving this code into "Setup Render" method and
>> > hitting
>> > the refresh button many times - this will work also with Firefox.
>> >
>> > I'm writing about this because Tapestry documentation creates sense
>> > of false
>> > security because it states that Page classes could be written in not
>> > thread
>> > safe manner (what is true when you do not have persistent fields)
>> > but this
>> > statement does not hold in all the cases.
>> >
>> > I played with the locks in the session and it kind of worked (you
>> > can make
>> > another request to wait or raise a exception to indicate duplicate
>> > request).
>> >
>> > When anyone has more ideas about this problem then I'm more than
>> > thankful to
>> > hear about them.
>> >
>> > Regards,
>> > Kristjan Kelt
>> > --
>> > View this message in context:
>> http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp2
>> 4468298p24468298.html
>> > Sent from the Tapestry - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> --- original Nachricht Ende ----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/T5-Page-field-persistance-and-multithread-problems-tp24468298p24475427.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org