I think that can be done on a framework level with optional parameter
or annotation such as:
@Persist(lazy-thread-safe-session)
that locks in the beginning of the request and unlocks in the end.
However I don't think it's a priority feature.
As for me it's enough to just put reminder to
Sent: Tuesday, 14 July, 2009 17:03:22 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
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
Wizard SSOs are a typical example of the temporary state I mentioned. No one
else should be able to write to it and thus you don't need guards against
concurrent writes. Especially not, since you validate the business objects
before comitting them. But still it could be a neat idea in some
2009/7/14 Howard Lewis Ship hls...@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
Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
On Tue, Jul 14, 2009 at 3:10 AM, kristjankeltkristjank...@hotmail.com wrote:
Hi,
Peter Stavrinides wrote:
Kristjan, as Nille has explained to you that is simply not the case, what
:08:04 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: T5 Page field persistance and multithread problems
On Tue, Jul 14, 2009 at 3:10 AM, kristjankeltkristjank...@hotmail.com
wrote:
Hi,
Peter Stavrinides wrote:
Kristjan, as Nille has explained to you that is simply not the case
2009/7/15 p.stavrini...@albourne.com
Other than a flag that the framework will have to manage, I really don't
see it being such a big deal... maybe I am naive and missing something, but
do you think it is better for Tapestry users to manage this? having Atomic
references and Synchronized
, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
2009/7/15 p.stavrini...@albourne.com
Other than a flag that the framework will have to manage, I really don't
see it being such a big deal... maybe I am naive and missing something, but
do you think it is better
. 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
: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
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
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
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
...@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
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
to the ServletContext.
Peter
- Original Message -
From: Robert Zeigler robe...@scazdl.org
To: Tapestry users users@tapestry.apache.org
Sent: Tuesday, 14 July, 2009 17:03:22 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
Alfie
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
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
-field-persistance-and-multithread-problems-tp24468298p24468298.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
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 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 Zeiglerrobe...@scazdl.org
Well, it /is/ the case
21 matches
Mail list logo
