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
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 the case, what
>> is happening is multiple requests are being generated when the submit
>> button is clicked more than once, each of these Req
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 man
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
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 r
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
>
> Hi,
>
>
> Peter Stavrinides wrote:
> >
> > Kristjan, as Nille has explained to you that is simply not the case
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 modif
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'
>
> 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
&
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
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
20 matches
Mail list logo
