threadsafety in jsp/servlet

thanks

>>>>   <%@ page isThreadSafe="false" %>
Shouldnt it be   isThreadSafe = "true"  ? (since we want to make the servlet thread-safe)


<<<you will have N instances of the servlet loaded and initialized

How will 'N' be determined ? What if there are N+1 threads accessing the servlet ?
Is there a way to configure the N ?

can i just use synchronized(this) to fix the problem..but again it is a servlet..
so how would the thread-safety be different in this case..

thanks

In what way do you think the original code is not thread safe?

The variable "i" in your code is local to the method and so it will automatically be "thread safe".  You could have 100 threads all executing this code at the same time and you would have no problems (each thread would create it's own local "i" variable).

The only time you'd need to introduce synchronize is if, for example, you used a static member variable - which would be shared between all instances of the class.  Then you should synchronize your accesses to that variable - but that's not happening here.

So as it stands you don't need to do anything.

Doug

>The variable "i" in your code is local to the method and so it will automatically be "thread safe".

Is this because the jsp compiles to a servlet  and servlet is threadsafe ?
In a java class this is not the case, two threads can access the variable "i" at the same time and cause race condition which would make i non-thread safe. correct ?

>>>The only time you'd need to introduce synchronize is if, for example, you used a static member variable - which would be shared between all instances of the class.  Then you should synchronize your accesses to that variable

<%
public void read()
{
static int i =0;   -- this would be shared across multiple instances , correct
i =  i + 1;
System.out.println(i);
}
%>

>> Is this because the jsp compiles to a servlet  and servlet is threadsafe ?

There's nothing special here about the jsp.  It compiles to a Java class (which indeed implements the servlet interface, but that doesn't matter).  Any Java class with only local variables will always be thread safe.

>> In a java class this is not the case, two threads can access the variable "i" at the same time and cause race condition which would make i non-thread safe. correct ?

No that's not correct.  You can't have a problem with a local variable between two threads.  Local variables are put on the stack and each thread has its own stack, so the two "i" variables can't interact with each other.

If you have a "static int mySharedInt" then yes, that variable can be seen by multiple threads (because it's not a local variable any more) and you would need to synchronize accesses to that.

BTW, the simplest way to do that today is:

static AtomicInteger mySharedInt = new AtomicInteger() ;

Declaring this as an AtomicInteger ensures all accesses to it will be thread safe and you can again skip worrying about synchronized.

Doug

Thanks... I guess i was confused a little after reading 'Doug Lea's book: concurrency in practice'

The book says the following two points

Servlets are threadsafe because they are stateless.
Anything declared private is thread-safe and immutable holder objects are threadsafe.

Any idea what that means in context to this question.

thanks for the explanation.

<%
public void read(String i)
{
i =0;    
i =  i + 1;
System.out.println(i);
}
%>
In above case where i is passed as a parameter, would it still be stored in stack?

Yes "i" in this case is still a local variable within the method and will be stored on the stack.

Doug