When we mention our servlet to be of a singleThreadModel, the container is going to create a new (or an existing one from the pool) instance of the servlet for every client request (even for the same client session). Isn't it going to be tricky for the container to get the data in sync with other instances of the servlet for the same client? Does this imply that its a bad idea to rely on instance data in the servlet and we should scope it to session (say)? Any thoughts on this.
Originally posted by Jayadev Pulaparty: Isn't it going to be tricky for the container to get the data in sync with other instances of the servlet for the same client? Does this imply that its a bad idea to rely on instance data in the servlet and we should scope it to session (say)? Any thoughts on this.
As you imply, you want certain data to be tied to the client, so of course that particular data should be scoped to a session. You're just guaranteed that no 2 threads (except possibly your own created threads if any) will simultaneously access the servlet instance, so you can have instance data that gets accessed by different methods of the same instance without having to worry about that data getting stomped on by another thread hitting methods simultaneously on the instance.
this doesn't make sense to me. if you have data that needs to be shared across multiple instances of a servlet, you are talking about a static class variable, and using a session is not going to help with this. if you are talking about sharing data across a user session, then the threading model for the servlet shouldn't matter anyway.... wait, are you thinking of creating an instance object, like a hash map to store user information for a servlet? if so, that is a case where having single threaded (and therefore possibly pooled) servlet instances could cause problems. but that is a strange design anyway, and something a session would better serve. or am i missing the point here?