What is a better approach for enabling thread-safe

[sai prasanna]

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]

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]

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

[Harpreet Hira]

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]

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:

synchronize(context) {
  // code accessing ServletContext
}

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 ]

[Christophe Verré]

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.

[sai prasanna]

iam thankfull to ranchers.

[Stan James]

You can avoid synchronization and race conditions by delegating all the interesting work to other objects.

doPost()
{
   String x = request.getParameter ...
   repeat for other parameters ...
   MyObject mo = new MyOjbect( );
   mo.process( parameters );
   do something with the results
}

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?

[William Brogden]

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]

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?