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.
I want to see some other opinions on the session management.
Let's assume we have the following two scenarios: 1) desktop application (client tier) working with EJB App Server (business tier) 2) web application (web tier) working with EJB App Server (business tier). In these two scenarios, the following options for keeping the the session data are available: 1) http session (web app), in some variables (desktop app) 2) statefull session bean.
Statefull session beans are more expensive comparing to stateless session beans. Business services (session beans) would require to have access to some of the session data, but this data can be passed from the client invoking the session bean. Therefore, some people might suggest to keep the session data in statefull session bean to avoid sending it forth and back each time. Well, others then would say that the presentation layer would need this data too. If so, keeping it in the preceding tier (web or client depending on the type of the application) and sending it to the business (EJB) tier seems to have the same performance as to keeping it in the business (EJB) tier and sending it back to the preceding tier (web or client depending on the type of application).
I am curios to get more comments on the pros/cons of these two options. Which one is the best approach, or which one is better for which specific situation.
PS: This topic is posted in this forum because I believe it is related to its purpose; however, if the moderators feel it should be moved to some other forum, please let me know.
Hi Alexi, You are right... SFSB are costly. But if you are using SFSB then it means that your EJB layer is having complete business logic and is self contained and the client layer (Web server) is worried only about presentation logic. This means that the Business component (EJB layer) can support any type of client (Web based or swing based etc) But the problem is you are not designing the software to be used in heaven. You are designing it to be used where price matters. you are clearly told that swing will be used or not even if they are used then how capable will be your app server and then you are never sure what changes will impact the system.
First of all exchanging data between HttpSession attributes and some of your EJBs is not the same as exchanging data between a Swing client and EJBs. The difference is fundamental. The general rule of thumb would be to use stateful EJBs for keeping personal data if you must support both web and application clients. If you have only web clients then keeping data in HttpSession will do the job. Thinking about performance don't forget about possible concurrency issues too...