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
