• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Where to keep the session data

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,

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.

Thanks,
Alexi

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.
 
Alexi G Jordanov
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys,

Any thoughts on this?
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks
Tanveer
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
reply
    Bookmark Topic Watch Topic
  • New Topic