• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to Interpret SingleThreadModel query( Drop your opinion)?

 
Srinivasan thoyyeti
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,
Given>
Is "count" thread safe ?
class MyServelet extends HttpServlet implements SingleThreadModel{
private static int count;

}

Given this is the only information:

Is it mandatory to consider servlet pool for MyServlet ?

because if we assume that pool will be there... then "count" not thread safe.
and if we think pool is not there then count is thread safe.

Any Suggestions on how we have to interpret the above question.
[ March 09, 2007: Message edited by: Srinivasan thoyyeti ]
 
Saurabh Kumar
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Here "count" is a static variable(belonging to the class and shared among instances). So it won't be thread-safe in any condition.

Thanks and regards,
Saurabh
 
Srinivasan thoyyeti
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi saurabh,

If you don't pool and and at any time only one thread is gonna execute. and remember no other servlet can access that because it is private.

Are you clear now... Please let me know what you feel !

Any Suggestions on how we have to interpret the above question.
[ March 08, 2007: Message edited by: Srinivasan thoyyeti ]
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Srinivasan thoyyeti:
Hi saurabh,

If you don't pool and and at any time only one thread is gonna execute. and remember no other servlet can access that because it is private.

Are you clear now... Please let me know what you feel !

Any Suggestions on how we have to interpret the above question.



You can only assume things that the specification guarantees. In this case, the spec doesn't guarantee that there won't be any pooling. So you can't assume that. It suggests that there might be pooling of servlet instances. You have to answer based on the understanding that pooling may be there, in which case, it won't be thread safe.

HTH,
Paul.
 
Srinivasan thoyyeti
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul Anil,

In this case, the spec doesn't guarantee that there won't be any pooling.
Your reply says there can be pooling means its 50-50. How can it be gurenteed behaviour ?

Coin as two sides.
Lets talk the other side of the statement.

Does specification said "There should be pooling if we implement SingleThreadModel" ?.

Please clarify. I don't want to argue here. But i want to know whether we are on right track !
[ March 08, 2007: Message edited by: Srinivasan thoyyeti ]
 
Srinivasan thoyyeti
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anybody clarify the issue Please.
 
Srinivasan thoyyeti
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From API( SingleThreadModel ) ...

If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method.

1)The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, (or)

2)By maintaining a pool of servlet instances and dispatching each new request to a free servlet.

------------------------------------------------------------
From API its cleat that "its container specific to ensure Single thread access"

Then There is no point in "taking into consideration that pool will be there when servlet implements SingleThreadModel"

Am i right..... ranchers.
Then whats the answer for query in first post.
Come on reply to me please...
 
Ulf Dittmer
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using a pool takes care of concurrency problems with non-static class fields, but not static fields. But if you don't use, the code should be fine.

There are other sources of concurreny problems, though, namely objects in sessions. That's why STM was deprecated, because it didn't actually accomplish what it set out to do - full thread safety.
 
Srinivasan thoyyeti
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulf,

You are so sweet. Thank you very much. Anyway it got deprecated in j2ee 1.4.
It won't be there for WCD 1.4 exam.

Thanks a lot.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic