Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Statefull session Bean Vs Servlets Session

 
kri shan
Ranch Hand
Posts: 1460
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How Statefull session Bean is better than Servlets Session?
 
Malli Raman
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by kri shan:
How Statefull session Bean is better than Servlets Session?


I think both are working in different context but for the same purpose as session tracking.

In the servlet session you have to store all the values explicitly but in SFSB the container does the job for you.

Using SFSB will hit the performance as one SFSB is attached with one client.

If your appln uses the servlet & SFSB then store the values in serlvet session instead of SFSB.
 
kri shan
Ranch Hand
Posts: 1460
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then what is the use of SFSB?
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

How Statefull session Bean is better than Servlets Session?

That�s not always true and is not actually the point. Only because SFSB and HttpSession can both be used for storing conversational state, it doesn�t necessarily mean that you have to compare both technologies only through this feature. They both have different capabilities and solve a different set of problems. However if you are strictly interested which of the two manages the session information better, then let me tell you this: HttpSession is preferred; and not only from a design persperctive, but here there is a strong reason why WebLogic recommends managing sessions through HttpSession.
For both HttpSession and SFSB WebLogic uses an in-memory replication algorithm within a cluster (I already explained this principle on this forum several times now). In order to replicate the HttpSession object WL keeps track of the data that changed in the HttpSession. WL can easily do that because the container knows that the clients call setAttribute() method in order to change the HttpSession object. Therefore the server will replicate only the part of the session that was changed and not the whole session object. However the container has no way to figure out which data was changed in a SFSB and which data was not; WL replicates always the entire SFSB.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic