Two Laptop Bag*
The moose likes Servlets and the fly likes Alternative to Single Thread model ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Alternative to Single Thread model ?" Watch "Alternative to Single Thread model ?" New topic
Author

Alternative to Single Thread model ?

Anand Athinarayanan
Greenhorn

Joined: May 20, 2011
Posts: 27
Hi All,
I was reading the Servlet 2.4 spec when I came across thread safety in Servlets. From the spec,

The use of the SingleThreadModel interface guarantees that only one thread at a
time will execute in a given servlet instance’s service method. It is important to
note that this guarantee only applies to each servlet instance, since the container
may choose to pool such objects


I understand that If I implement Single thread model then the container may create more than one instance for each servlet as opposed to only one if i don't implement it.

I was just wondering, why isn't there a combination of both. The container creates multiple instances for each servlet and also take advantage of multi threading. This guarantees thread safety of servlets because each request will have a separate instance of the Servlet class. Why hasn't any container implemented such a model ?

I assume there are potential disadvantages to this model, can any of you list it out ? One disadvantage is creating servlet instances each time a request comes can be costly.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60741
    
  65

What would the advantage of such a model be?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Anand Athinarayanan
Greenhorn

Joined: May 20, 2011
Posts: 27
Well, our servlets can have instance variables and still be thread safe.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

And what would be the advantage of that?


Customer surveys are for companies who didn't pay proper attention to begin with.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60741
    
  65

Anand Athinarayanan wrote:Well, our servlets can have instance variables and still be thread safe.

No they couldn't. In a hybrid approach, some instances may be shared across threads and you'd still have to write servlets to be thread safe. Unless you are talking about creating a new instance for each request.

I still see no advantages, as Tim asks.

In the 14 years I have been writing servlets, I've never missed instance variables. It's just a tiny amount of effort to make sure that servlets are written in a thread-safe manner.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

I think a lot of people think that a servlet is a "program". It isn't. It's actually more like a specialized form of Stateless Session EJB, although it predates EJBs and is invoked by the webapp server instead of an RPC-style application function.

Or, if you prefer Windows terms, it's more like a functional component in a DLL.

While you can certainly define both member and class variables in a Servlet implementation class, there are J2EE constructs that do that and generally should be used instead. In particular, an instance variable usually functions better as a Session property. No threading issues, and each and every user gets a unique instance.
Anand Athinarayanan
Greenhorn

Joined: May 20, 2011
Posts: 27
Bear and Tim,
Thank you for your replies. Writing thread-safe servlets is more efficient than the alternative to single thread model.

While you can certainly define both member and class variables in a Servlet implementation class, there are J2EE constructs that do that and generally should be used instead


I've never seen a member variable in a Servlet before. What do you mean be J2EE constructs that do that ? Can you give me an example.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 9913
    
158

I think Tim means using other "components" within the Servlets, as member variables. For example, Java EE allows you to inject EJBs within the member fields of your servlet:


Setting that field is the responsibility of the Java EE container and it knows when to set it.

[My Blog] [JavaRanch Journal]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Jaikiran Pai wrote:I think Tim means using other "components" within the Servlets, as member variables. For example, Java EE allows you to inject EJBs within the member fields of your servlet:


Setting that field is the responsibility of the Java EE container and it knows when to set it.


Actually, I mean in general. Doesn't matter who sets them or how. It's very unsafe to have member variables, since not only are they not thread-safe, there's no actual reason why a webapp server couldn't construct multiple instances of the servlet class (at least in the original spec). And, of course, each one would have an independent and possibly conflicting set of member property values.

It's the difference between what you can do and what you should do.
shraddha sawant
Greenhorn

Joined: Sep 06, 2011
Posts: 12

Bear Bibeault wrote:
Anand Athinarayanan wrote:Well, our servlets can have instance variables and still be thread safe.

No they couldn't. In a hybrid approach, some instances may be shared across threads and you'd still have to write servlets to be thread safe. Unless you are talking about creating a new instance for each request.

I still see no advantages, as Tim asks.

In the 14 years I have been writing servlets, I've never missed instance variables. It's just a tiny amount of effort to make sure that servlets are written in a thread-safe manner.



Here, you have mentioned hybrid approach. What does it exactly mean. I am new to j2ee concepts. just i studied about 4 approaches using which we can have Thread Safe servlets.
1. using all local variables
2. protected synchronised service() method
3. synchronised blocks
and 4. Implementing SingleThreadModel interface. ()
Which is mostly used approach? will you please explain? or is there any another approach which is being used?


shraddhasav
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

The preferred approach is not to single-thread at all. Single-threaded functionality scales badly.

Failing that, you can use synchronized methods in the servlet, although it's usually better to offload complex logic to a POJO business bean that the servlet references.

Another approach is to use Session EJBs, although not all webapp servers have built-in support for that (Tomcat, for example).

For long-running serial functions, construct an engine thread and have the servlet queue up work to the engine.

If by using "local" variables, you mean member variables, don't even think about it. As we've already mentioned, member instance variables are not inherently thread-safe.
 
 
subject: Alternative to Single Thread model ?
 
Similar Threads
Local Vs. Global - Results
SingleThreadModel Vs Concurrency
servlet pooling
servlet pool
Single Thread Model