There are different session handling mechanisms like URlRewriting,Httpsession,cookies,hidden from fields.
everyone has their own advantages and disadvantages.

But when you are going for STATEFUL SESSION BEANS ,how is the state maintained ,is it totally maintained at the server part.(cant we maintain the same without STATEFUL SESSION BEANS by using the above mentioned sessio0n mechanisms).
 I meant was if U R using the above mentioned session handling mechanisms,Then where does the concept of Stateful session bean applies
here.
 Plz do calrify

Servlets and JSPs, which use those session handling mechanisms, are part of the presentation logic. Stateful session beans, however are part of the business logic.

URLRewriting and the like is useful for identifying users over a stateless protocol like HTTP, but it shouldn't hold any information other than an unique key.

Within pure web applications (without EJBs), information is stored by the servlet container. This works like a HashMap.

On the other side, stateful session beans do more than just holding information. They perform business logic using their actual state. Servlets and JSPs are clients to the EJBs and therefore should not know more about the business logic than any other EJB client.

Hi,
Please go through the following url, to find out other advantages of using statefull session beans.

http://www.precisejava.com/javaperf/j2ee/EJB.htm#EJB114

Hi,

Only use stateful session beans if you really need to. As you note, there are many other techniques you can use which are readily understood.

EJB is slow, and the benefits of presistance of state in middle tier, app server security, cluster stability etc are often irrelevant to the problem at hand. Which is why I say only use them if you really need to.

Jonathan

If you are using Stateful Session Beans to hold user state in a web application, there are some issues that you need to be careful about - and they are nothing to do with the supposition that "EJB is slow".

Firstly, if you are developing a web application, you will still need to use "session handling mechanisms like URLRewriting, Httpsession, cookies, hidden form fields" etc. The question is where to store your session state if such state needs to be stored.

Some people say that in order for an application component to be scalable it must be stateless. While this holds true for some situations, statelessness can itself be a scalability limiting factor where it results in increased passing of state over the network (from database or from client). Therefore this idea that "statelessness == scalability" is untrue as a blanket statement. There is ALWAYS state in an application - the question is just where to keep it.

Now, in a web application, a significant limiting factor of using stateful session beans is that Stateful Session Beans do not support concurrent access. This means that your servlet (or, better still your SFSB delegate) must synchronise access to the stateful session bean. Your Application server might support this synchronisation for you (e.g Weblogic does) - but while this is allowed, it is not not part of the standard and hence only portable if other appservers also support it.

The other issue of consideration is where (if it exists) the network break is in you application. If you have stand-alone servlet engine that calls the EJB layer (say, though a firewall) then your calls to the Stateful Session Bean means a network call - and this may be unacceptable for response time if your Session Bean has a fine-grained access. What you DO want to avoid is duplication of state by storing it in more than 1 place. Therefore, resist the temptation to use statefull session beans AND cache their state in the HTTPSession object.

In general, if you dont require the transactional support for your state that SFSB's can offer, HTTPSessions may be a simpler alternative.