Hello John,
>>
>> In this case, you wouldn't use the page activation context, as you're
>> filling the page properties yourself. As Tapestry uses redirect-after-post
>> by default (and not using it can lead to several problems), you would need
>> to @Persist("flash") the property in all pages. The single giant ASO would
>> be a better fit instead of this.
>>
>
> thanks for correction. But the single giant ASO would not be scalable for
> us as there will tens of thousands of concurrent users.
>
You can off course disable redirect-after-post and track resubmissions
with different mechanism. In theory one could generally think about
storing data on the client side, i.e. in the hidden form fields or in
the URL. Please note that when discussing the solution we are
generally speaking of limitations/features of the Web applications in
general, you would have the same issues wherever web application you
would have, i.e. T5, Spring Web Flow, JSW, Ruby on Rails of PHP.
Stateless nature of HTTP communication is the reason, not the
technology in use.
IMHO heavy session state is generally not good, due to the overhead of
session state replication in the cluster nodes, however some load
balancing techniques (e.g. sticky sessions) could be a acceptable
solution.
In case user state is not stored in the session then it should be
stored somewhere else - e.g. on the user side. It means that you could
either encode the state in the URL (and keep in mind the limitations
of the URL length). Other possibility is hidden form and POST. You can
use/extend the Form tag to encapsulate additional fields that will
store the user state (I'm quite sure this functionality is already
exists in T5).
So basically it's only a question where to store user state - on
server (HTTP Session) or on client (and transfer it with every
GET/POST request). Server solution is considered to be not scalable
enough. However client solution is also not free from problems. For
example let's imagine we have 500 kb of the user state. In case we
will store in on client it will be attached to every client request,
so request size will really increase. What will also be increased is
the request processing time because any data sent from the client can
not be trusted, therefore apart from network latency and
deserialization time we need to consider validation/decryption
overhead. The server-side solution will generally work faster due to
the fact that most of the clusters have gigabit ethernet between nodes
:) and server-side data is protected. Some solutions like sticky
sessions will minimize the whatsoever overhead we will have.
Another good question is what is stored in the session. And here we
come to the point where development framework makes huge difference.
Tapestry have "Static structure - dynamic behavior" principle which
leads to some limitations (e.g. can't create components runtime),
however it's a huge advantage which heavily limit the HTTP Session
usage. With T5 one can write a stateless applications - i.e. HTTP
session is not used at all. Try it with JSF :)
P,S, Sorry for the long post.
--
Best regards,
Renat Zubairov
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
