aspose file tools*
The moose likes Servlets and the fly likes What is a better approach for enabling thread-safe Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "What is a better approach for enabling thread-safe" Watch "What is a better approach for enabling thread-safe" New topic
Author

What is a better approach for enabling thread-safe

sai prasanna
Ranch Hand

Joined: May 02, 2005
Posts: 167
hi all,

What is a better approach for enabling thread-safe servlets and JSPs? is it through SingleThreadModel Interface or Synchronization?

thanks in advance
saiprasanna
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12803
    
    5
SingleThreadModel was a concept created before people had really figured out the best practices for programming servlets. It survives in the API for backwards compatibility only.
Bill
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

To underscore William's excellent response..
SingleThreadedModel has been deprecated.
It is never a best practice to use deprecated classes when writing new code.


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Harpreet Hira
Ranch Hand

Joined: Sep 27, 2001
Posts: 72
I think you don't have much choice but to synchronize. But synchronization should be applied sensibly on objects which shouldn't create bottlenecks for the application.
The HttpSession object, ServletContext object and servlet instance variables needs are NOT thread safe and should be handled carefully.
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
You should avoid synchronising as much as possible - for example, unless you intend for multiple servlet invocations to share the same instance variable (which can happen with things like database Connections, although a pool is better), you should avoid instance variables. If you do use them, you should be careful with the synchronisation if your invocations of that instance are more than atomic operations. Generally I would advise trying to create a different construct in your design if you find yourself synchronising a lot (e.g. for database Connections use a factory or pool).

The only standard J2EE objects you should synchronise, if thread safety is a concern (and it isn't always), are HttpSession and ServletContext simply because these can be accessed by multiple servlets concurrently. However, if all your servlets only ever read data from these objects (i.e. don't use their scoped attributes), it is unnecessary to synchronise. For example, you wouldn't synchronise when obtaining context initialisation parameters because they are immutable after application start-up.

For these objects, if your ServletContext variable was called context, you would use:only in the places within the methods where you need to access the context. You shouldn't use synchronized methods in servlets - but they're fine of course in JavaBean helpers.

Oh, and never use the deprecated SingleThreadModel.
[ May 10, 2006: Message edited by: Charles Lyons ]

Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14688
    
  16

That would be nice to hear from you, sai prasanna, when people answer your questions. You're asking a lot, but never give any feedback. Just let us know that you've understood what the other ranchers have told you.


[My Blog]
All roads lead to JavaRanch
sai prasanna
Ranch Hand

Joined: May 02, 2005
Posts: 167
iam thankfull to ranchers.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
You can avoid synchronization and race conditions by delegating all the interesting work to other objects.

Note that MyObject gets plain old parameters, no J2EE classes like request, response, session, etc, so you can unit test it without firing up the whole server and navigating through a bunch of pages.

What do you think of the cost of creating a new MyObject every time? Potentially a problem?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12803
    
    5
Note that MyObject gets plain old parameters, no J2EE classes like request, response, session, etc, so you can unit test it without firing up the whole server and navigating through a bunch of pages.

Exactly
Note that you can generalize things further by getting all request parameters as a Map with the getParameterMap method so you can define the process( map ) method.
Bill
Vishnu Prakash
Ranch Hand

Joined: Nov 15, 2004
Posts: 1026

What do you think of the cost of creating a new MyObject every time? Potentially a problem?


Doesn't that affect in terms of memory?


Servlet Spec 2.4/ Jsp Spec 2.0/ JSTL Spec 1.1 - JSTL Tag Documentation
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What is a better approach for enabling thread-safe