Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What is a better approach for enabling thread-safe

 
sai prasanna
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13058
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
iam thankfull to ranchers.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13058
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1026
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic