Hi Renat,
First thanks for the detailed discussion.
On Wed, Oct 8, 2008 at 2:16 AM, Renat Zubairov <[EMAIL PROTECTED]>wrote:
> 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.
>
I understand where you are coming from. Stalelessness of the HTTP is a best
& worst thing for the web developement depending on the application you are
developing. But I hear there is some kind of work around for it with Spring
Web flow & JSF. I am exploring that to understand more on how they deal with
this issue. I am also wondering if this is a feature that Spring Web Flow
offers then why not integrate it with Tapestry?
>
> 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.
>
In theory the Client side storage is an interesting option from
technological point of view. But it is an option that we are not allowed to
have coz of the same concerns you have already stated. The security of the
data, overhead and the request size are also of huge concern to us.
I am sure we are the first ones to face a challenge like this and there must
be some kind of workaround to manage the state without overkilling the
servers when the users scale.
>
> 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.
We are glad you gave us the whole big picture. Thanks for the insights
mate.
>
> --
> Best regards,
> Renat Zubairov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Cheers,
John
