Are you using "View" in the proper sense? Did you mean "page"? A view is created in direct response to a request to load a page and includes information about the backing bean, binding to the view state, etc. If two users go to the same page they will get a different view instance but whether or not the data displayed is the same is up to you.
Thanks Robert. We are on the same page there. Given that my page is not user specific, how can I share the instances and not have the JSF Framework create 2 of those. Essentially I am trying to reduce the memory footprint and increase the overall scalability and the # of views created is hurting.
I don't believe you can share views in anyway. There are a couple things you can do if you have resource limitations (you may have already tried them).
1) Reduce the scope of your views. If you're using session scope, view scope, etc the view will last a lot longer. If you can use request scope you will need less views.
2) Reduce the total number of views saved. MyFaces defaults to 20. web.xml org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION. The downside is that if a user navigates back to a previous page using the browser side cache and then attempts to post to the expired page you'll get the evil "ViewExpiredException".
3) Use client side view saving rather than server side. This means your view will be sent to the client encrypted and sent back to you on the post back. This is useful in applications where you have lots of clients and don't want to encure the cost of saving the views on the server. web.xml javax.faces.STATE_SAVING_METHOD
4) Of course you can also reduce the amount of data you save in your bean.
5) Compress the views on the back end. web.xml org.apache.myfaces.COMPRESS_STATE_IN_SESSION
All the Myfaces JSF parameters are at http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
Thanks Robert, I've tried most of them, but will keep trying.. Changing the beans to a request/application scope (from session) reduced the overall footprint but increased the JSF memory footprint. I was a bit surprised because I was not expecting that. I have the # of logical and views in session to 1 already, and don't want to do client side state saving (just from a bandwidth standpoint). The data saved in the bean is the key, from what I can tell.
The memory analyzers are working well but they don't tie the JSF beans to the underlying RichFaces JSF objects, and that is making things a bit tricky..