This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ”<br>
Joined: Feb 09, 2005
Thanks. The "Work around for some common issues" section is nice for me. I run into those issues. Maybe I'll try these workarounds if I'll have time.
But can you tell me about this? "Don�t create managed beans in session scope. Always create in request scope." Why do you recommend it?
Joined: May 10, 2008
1. It is not scalable solution. Assume 100 concurrent virtual user application, session objects will consume more heap memory. You will get out of memory exception after sometime. 2. For real time data application keep the data in session will affect the data accuracy. 3. In clustered/ load balancing environment, replicating session is costly operation.
keeping session object as lean good for scalable application.
I was looking for an article on JSF best practices or architecture design and bumped into this thread. This conversation about not implementing session managed backing beans is interesting.
About the three reasons for not implementing session backing beans I would argue the following.
I'm currently developing an application where we've had to make a lot of use of session beans because it has to deal with a few workflows. Now, Here's what we are doing. Each interface is related to a corresponding request managed backing bean which stores objects of Collection<selectItem> to build the combos, HashMap<Integer, Boolean> for checkboxes, navigation methods for the buttons and other interface related elements. Now, when an interface needs to render a collection of objects for a search, the search criteria is handed by the request managed bean to a session managed bean which in turn querys the data base and stores the result in heap memory for further use. I this querying were done directly from the request managed backing bean you would loose the ability to keep the result for further use, thus producing the overhead of having to query the data base again and again with each new request. So, of course there is a trade off to only using request managed beans. I would say that if your request managed beans involve frequently used data base queries, you might want to take another look at session managed backing beans, specially if the queries are heavy (nested or sweeping a lot of data).
I don't really know if there is a better way to develop a jsf architecture. I'm currently doing a lot of research and trying to attempt variations of the former pattern.