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 "Pers
age -
> From: "Robert Zeigler"
> To: "Tapestry users"
> 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
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
circumst
rut, Bucharest,
Istanbul
Subject: Re: T5 Page field persistance and multithread problems
2009/7/15
> 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 T
2009/7/15
> 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 blocks all over our code, i
nd modules through a facade where all the transaction
handling,locking, ... is done.
g,
kris
p.stavrini...@albourne.com
15.07.2009 09:15
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: T5 Page field persistance and multithread problems
> I suppose
: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, kristjankelt wrote:
>
> Hi,
>
>
> Peter Stavrinides wrote:
>>
>> Kristjan, as Nille has explained to you that is simply not t
2009/7/14 Howard Lewis Ship
> 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 wh
nce 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
> --
> V
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
ss to the ServletContext.
Peter
- Original Message -
From: "Robert Zeigler"
To: "Tapestry users"
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, ma
tiple 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
lt [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
> 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 fro
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&#
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-pe
uesday, 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'
lse
>> > 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.
>> >
>> >
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
> Well, it /is/ the case that page fi
as 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 Tapes
ge 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-unsubscr...@tapest
21 matches
Mail list logo
