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<robe...@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-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--- original Nachricht Ende ----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
