About Servlets lifecycle...

[James Turner]

Hi Guys,

I have just started studying for the SCWCD exam and I have one question about the servlet lifecycle.

It seems very, very, very similar to a stateless session bean, why, oh why, isn't there a servlet instance pool? The idea of many threads executing against one instance can cause many multi-threading issues with class state variables.

I think that the stateless session bean's lifecycle would be far more suitable for a servlet.

Does anyone have any comments about this? Any reasons why the servlets lifecycle is the way it is and not like a stateless session bean?

Thanx for your replies.

James.
[ November 17, 2004: Message edited by: James Turner ]

[Mikalai Zaikin]

Hi James,

Servlet Container actually allows you to emulate Stateless SB behaviour: you should implement SingleThreadModel interface in your servlet or JSP (isThreadSafe="false").

In this case Servlet Container either will create pool of servlet instances or will serialize request and put in queue to 1 servlet instance (Servlet specification does not mandate which approach should be implemented). What is guaranteed: only 1 request will be served by 1 instance of servlet at 1 moment of time.

But, just FYI - this practice considered bad, and SingleThreadModel interface is *deprecated* (AFAIR) in Servlet 2.4 API.

When only 1 instance of any servlet exists that saves much memory.

And, yes, as you mentioned - you should be careful about thread-safety while developing web application. That's why the exam tests knowledge of thread-safety of attributes/variables in different scopes.

regards,
MZ

[James Turner]

Hi Mikalai,

Thank you for the response, I think the SingleThreadModel interface sounds like a great way to program servlets and shouldn't have been deprecated. I mean, it makes the programming methodology and code much cleaner. With regards to session attributes, this should be implemented with a synchronized collection to guard against concurrency issues.

In my opinion, I think servlet programming should be only along these lines, as this would alleviate the programmer from threading issues, in a similar way EJB's do.

Does that sound more or less correct or are there reasons that I haven�t thought about that would mean this still would not work.

Thanx for any comments.

James.

[Shiang Wang]

SingleTheadModel is not thread safe. Whatever variables or attributes (in HttpSession, ServletContext) are not thread safe in 'MultiThreadModel', they are still not thread safe in SingleThreadModel.
Because you have multiple instances in the pool, the instance variables that is thread safe in 'MultiThreadModel' are not thread safe in SingleThreadModel. It is a common misconception that SingleThreadModel is thread safe.

Shiang