Skip to main content

[webtier] numberOfViewsInSession and numberOfLogicalViews question and recommendations

4 replies [Last post]
Anonymous

Hi all

I'm curious about which values people are using for these context
parameters.

I'd also like to know of my understanding of them is corret.

numberOfLogicalViews:
This corresponds to actual view ids or actual URLs.

numberOfViewsInSession:
Interpretation 1)This is the number of pages with the same viewId (logical
view) which will be saved.
Interpretation 2) The maximum of views stored! Don't think this is true
since value for this less than LogicalViews wouldn't make sense.

So with the default values of 15 for each of these parameters the worst case
scenario, with interpretation 1, would be that 15*15 views could be held in
the session for each user. Is this correct?

Or is Interpretation 2 correct so there will never be more than 15 views
kept in the session for each user?

Many thanks,
Micke
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rlubke
Offline
Joined: 2003-08-21
Points: 0

Hello,

Please see this FAQ entry [1] on Mojarra state saving. I think this should clarify their usage.
If not, please follow up here.

Thanks,
-rl

[1] http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI#section-J...

Mikael Andersson

Hi

Actually read the first part on in the FAQ which contains the description of
the parameters.
Now that I've read the example found just below, it is a bit clearer and I
think that my "interpretation 2" is what happens. Except that it isn't
really the viewId which is used but some state marker.

Please correct me if I'm wrong.

Very interested in hearing what values you guys out there are using, to me
potentially keeping 225 vewstates in memory for each user sounds a bit
excessive.

Many thanks,
Micke

2008/7/21 :

> Hello,
>
> Please see this FAQ entry [1] on Mojarra state saving. I think this should
> clarify their usage.
> If not, please follow up here.
>
> Thanks,
> -rl
>
>
> [1]
> http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI#section-J...
> [Message sent by forum member 'rlubke' (rlubke)]
>
> http://forums.java.net/jive/thread.jspa?messageID=288084
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>
>
[att1.html]

rlubke
Offline
Joined: 2003-08-21
Points: 0

If memory utilization is a concern, using 1.2_09 you can enable com.sun.faces.serializeServerState which will serialize and then compress the server state. There are costs with doing this of course as serialization isn't cheap, but the memory savings is significant.

Other things to consider is reviewing your component usage. If there is no real reason for a component to maintain it's state between requests, ensure you mark the component transient so that it's state isn't saved.

I don't have any magic bullets for how you should configure these parameters.
I've gone through the code and see that we could improve logging to show how these maps are being
used to make it easier to tune so I've logged an issue [1] to track this.

For now I would say the best way to figure out the best options for your application is by running through some of the typical workflows and then inspect the maps maintained with the session. You could use special application logic that pulls the maps from the session and displays information about them, or you could attach a debugger and pick through the session that way. The state maps are stored in the session using the key com.sun.faces.logicalViewMap.

[1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=760

Mikael Andersson

Thanks for the detailed post Ryan, you're ace.

I'll be discussing our requirements in terms of for how man back clicks the
back button needs to behave with the other devs.

Still curious about our users settings.

Cheers,
micke

2008/7/22 :

> If memory utilization is a concern, using 1.2_09 you can enable
> com.sun.faces.serializeServerState which will serialize and then compress
> the server state. There are costs with doing this of course as
> serialization isn't cheap, but the memory savings is significant.
>
> Other things to consider is reviewing your component usage. If there is no
> real reason for a component to maintain it's state between requests, ensure
> you mark the component transient so that it's state isn't saved.
>
> I don't have any magic bullets for how you should configure these
> parameters.
> I've gone through the code and see that we could improve logging to show
> how these maps are being
> used to make it easier to tune so I've logged an issue [1] to track this.
>
> For now I would say the best way to figure out the best options for your
> application is by running through some of the typical workflows and then
> inspect the maps maintained with the session. You could use special
> application logic that pulls the maps from the session and displays
> information about them, or you could attach a debugger and pick through the
> session that way. The state maps are stored in the session using the key
> com.sun.faces.logicalViewMap.
>
>
> [1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=760
> [Message sent by forum member 'rlubke' (rlubke)]
>
> http://forums.java.net/jive/thread.jspa?messageID=288436
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>
>
[att1.html]