Hi,
I have a question regarding this... I understand that in 1.3, previous page
states are serialized to the file system and only the current page state
stays in HttpSession. How would this work in a clustered web container that
synchronizes the HttpSession object to other nodes? Do you lose the history?
Thanks,
- Patrick
On 7/13/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
the number of pages an applicaiton has not not importand
in 1.3 we only keep 1 page per pagemap in memory
so just calculate the average page size and that will be your session
usage.
johan
On 7/13/07, James Law <[EMAIL PROTECTED]> wrote:
>
> Thanks Eelco for the response!
> I appreciate the update. As I am trying to sell wicket for use on a lot
> of applications, I do see the knee-jerk you describe. I am not concerned
> about memory usage, but more about the ability to persist it (via
> session persistence) efficiently, because I work in health care, a lot
> of people here are all about 99..999 availability, and of course
> appserver clustering always comes up in this discussion.
> I am optimistic that having a reasonably sized page history, and using
> idetachable models should keep things to a reasonable size. Do you have
> any experience using session persistence with a medium size app (say
> 50-100 pages)? eg> what session size can we expect?
>
> Thanks again
>
> James
>
> Eelco Hillenius wrote:
> > On 7/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> >> the real client side wicket , so storing the data in the browser
> didn't make
> >> it
> >> and i don't think it will make it very soon because no current
> committer
> >> really sees
> >> the big benefit of this approach.
> >>
> >
> > Yep. We played with it a while ago and we have a fair idea how to do
> > it but we felt it wasn't worth the energy to keep working on it.
> >
> > There are disadvantages to client side state saving:
> > * First of all you'd lose the secure-by-default model you have with
> > Wicket. For instance, imagine having a detail panel for a product. If
> > you pass around objects (or ids) on the server side, there is no way a
> > client could get access to the details he/ she is not supposed to see.
>
> > When passing state via the client, you would always have to check the
> > incoming state for misuse. This is actually a pretty strong feature
> > Wicket has over most other frameworks. The other side of this is that
> > if you want to have your whole app bookmarkable, you'll have to do
> > some extra work :)
> > * Secondly, synchronously serializing, encoding and sending the state
> > to the client eats processor time and bandwith. The size of the
> > serialized, encoded state will be larger than than on the server. Even
> > if we do something really smart, chances are we're sending *at least*
> > 20KB to the client on each request. Maybe even more. We think using
> > RAM is way more favorible.
> > * Last but not least, GETs have to be made POSTs or you'd have to run
> > the risk that state doesn't fit a request.
> >
> > Of course, there are advantages to client state saving as well:
> > * No worries about RAM, at least not because of Wicket[1].
> > * Pages are recoverable by default. Even when a session times out, you
> > could let the client pick up where he/ she left.
> > * No need for session affinity[2]
> >
> > Conclussion: we don't support client side state saving currently, and
> > we don't feel it's a priority at this time. However, if someone does
> > feel it is important, we'd be more than happy to look at patches. I
> > think the easiest way to achieve this is to implement it as a
> > IResponseFilter and a custom session store.
> >
> > Eelco
> >
> >
> > [1] worrying about using RAM is the typical knee-jerk reaction of
> > people. Before worrying, calculate how many concurrent sessions you'll
> > have to support, and how much RAM you'd need for that.
> > [2] this increases your options when it comes to the way you cluster,
> > though not using session affinity can have disadvantages as well (for
> > instance when using ORM caches).
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> >
> >
>
>
> -------------------------------------------------------------------------
>
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
