Stateful Session bean or Servlet Session as stateholder?

[James Turner]

Hi Guys,

I have seen some scenario mock exam questions for part 1 that describe a set of requirements for a system and then ask what components of the J2EE platform best suit each individual entity of the system.

I have a question about when it is appropriate to use a stateful session bean or a Servlet session object as the mechanism to hold the user's state. (Assume EJB's are being used, i.e. for transactional and persistence requirements).

There does not seem to be any clear requirements about such things. I assume the correct choice of either state holder is due to performance, but I am not sure what sort of load is appropriate for a SFSB compared to a Servlet Session? Are there any other factors?

Thank you for any help, much appreciated.

James.

[Manoj Kumkumath]

when it is appropriate to use a stateful session bean or a Servlet session object as the mechanism to hold the user's state

The following are my understanding.

1) I will go for maintaining session in Stateful Session bean if my business components can be accessed by different ways or in future have the chance to use more than browser to access. Using servlet Session binds me to http.
2)If my object is getting created/modified by calls to many services, I will keep it in Ejb session. Making calls to three services from EJB layer will be more better from making call from web layer.

-Manoj

[James Turner]

Is there a threshold in terms of performance only that would specify using session beans over a servlet session? i.e. a site gets 100,000 hits a day what is more appropriate for holding a user's session state, session beans or servlet session?

EJB's are meant to be used when there is heavy load regardless of any other requirements, but is there a hard and fast rule as to the quantity of load a site can take before it is appropriate to move the state to session beans?

I have seen many questions that include this scenario but I havn't found any actual numbers in terms of load that specify either option.

If anyone has any info on this type of scenario I would greatly appreciate it.

Thanx,

James.

[Required Field]

Other than what has been said already, I would assume that an SFSB would be the right choice for distributed session tracking!

Meaning if you had multiple web applications (for e.g. Yahoo's Mail, News, Search, Briefcase, Calendar etc) and wanted a single-sign-on like feature, it would be really neat to maintain user's session related information in one SFSB, centrally accessible by a JNDI name!

If you do this using servlet's HttpSession mechanism, you will have to devise your mechanism (like store in a database, or use pre-packaged session tracking software) to make the session data available in a distributed fashion across all the web apps.

Please correct me if my assumption or theory here is wrong? I haven't passed the part I exam yet, although I am preparing for it and plan to give the exam in the next one month's timeframe!

Thank you!

Originally posted by James Turner:
Is there a threshold in terms of performance only that would specify using session beans over a servlet session? i.e. a site gets 100,000 hits a day what is more appropriate for holding a user's session state, session beans or servlet session?

EJB's are meant to be used when there is heavy load regardless of any other requirements, but is there a hard and fast rule as to the quantity of load a site can take before it is appropriate to move the state to session beans?

I have seen many questions that include this scenario but I havn't found any actual numbers in terms of load that specify either option.

If anyone has any info on this type of scenario I would greatly appreciate it.

Thanx,

James.

[arvindh seshadri]

Choice of EJB or servlets for session management may be dependent on the foll factors

1. transaction- if transactions are involved then EJB as they offer declarative transaction management.
2.Light weight session management - servlets are better.
3.Servlets are boundary to the system and support concurrency and session management and hence can be exposed to the external world as opposed to EJB . EJB always adds more layers ( BD, SL, PROXY, HOME FACTORY) and can be exploited in intranet applications and SOA within enterprise .



Thanks,
Arvindh