Honestly, I doubt if the question was framed properly. Also, this statement:
In short, as far as possible, we should avoid making use of stateful session beans. why is it so?
Maybe the answer was expected to be in the lines of a school of thought "stateful session beans do not scale as well as stateless", which I personally feel is just an off-the-cuff remark. Also, was the question asked without a context? Where you need to store the context is entirely dependent on key parameters such as granularity of the transaction.
In most of my interviews they usually ask "how do you decide when to use Stateless vs Stateful beans". Here is the tyical answer I give
Stateful Session Bean Considerations: Stateful session beans are appropriate if any of the following conditions are true: 1)The bean's state represents the interaction between the bean and a specific client. 2)The bean needs to hold information about, or on behalf of, the client user conversational state across method invocations. 3)The bean mediates between the client and the other components of the application, presenting a simplified view to the client. 4)Behind the scenes, the bean manages the work flow of several enterprise beans.
Because stateful session beans are private to a client, their demand on server resources increases as the number of users accessing an application increases. The beans remain in the container until they are explicitly removed by the client, or are removed by the container when they timeout. The container needs to passivate stateful session beans to secondary storage as its cache fills up and the beans in the cache timeout. If the client subsequently accesses the bean, the container is responsible for activating the bean. This passivation/activation process imposes a performance overhead on the server.
Stateless Session Bean Considerations: You might choose a stateless session bean if any of these conditions exist: 1)The bean's state has no data for a specific client, that is, user conversational state does not have to be retained across method invocations on the bean. 2)In a single method invocation, the bean performs a generic task for all clients. 3)The bean fetches a set of read-only data (from a database) that is often used by clients. Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month.
Use a stateless session bean to access data or perform transactional operations. Stateless session beans provide high scalability because a small number of such beans managed by the container in a stateless bean pool) can help serve a large number of clients. This is possible because stateless beans have no association with the clients. When a request for a service provided by a stateless session bean is received, the container is free to dispatch the request to any bean instance in the pool.
Real Context example: Let say in an ecommerce site. A stateful bean can be used to maintain the state of the user. From the point he adds the first item to the cart to the point of order completion. Stateless beans can be used in the middle for non-client specific actions like getting list of all items on promotional sale.
Sudhir V<br />(SCJP 1.2, SCWCD, OCA, SCBCD)
You get good luck from rubbing the belly of a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop