I have few questions. As far as I know, every request to a container becomes a HttpServletRequest. More request-> more instances of HttpServletRequest. Then, when a request object calls a servlet called 'abc', an instance of 'abc' servlet is created. Let's say same time 3 requests come to 'abc' servlet ,then
(1) I want to know ,does it mean, 3 instances of 'abc' servlet per each request are created? or requests are queued till one request to the servlet is done.
Then let's say,3 request to 'abc' servlet do some database processes which could be insertions and retrieves at the same time. Then
(2) does one request should be in the queue until other request's servelt completes the task (synchronize)or all servelets do their DB task as multi threads as seperate tasks(not sinchronized) ?
(3). If they work as not synchronized, how can we make those tasks synchronized (lets say, only one particular task-save some thing to DB) and queued ? to do so, is it better to implement the servlet SingleThreadModel or use a method which is in a class created according to singleton pattern ? Then how it affect to the performance of the container?
In short,how can we run a particular task synchronized for all requests ?
I read this as well. That article says about servlets. Lets say the task of a servlet is handed over to another class, then I would like to know how about using singleton pattern on this?
A container may create a pool of servlet instances (an excerpt from a servlet spec below explains the details). It may use three different instances for three concurrent requests or may use one for all three. Your servlets thus need to be thread safe and shouldn't have state in their member variables. The SingleThreadModel marker interface will signal to container not to use same instance of the servlet for more than one concurrent request (thus making your servlet thread-safe) but it won't prevent the container from creating multiple instances and using them simultaneously. makes sense? if your operation requires synchronization then you handle it in your Model classes, not your Controller. So basically synchronize (or queue things up) elsewhere is the answer. Let the servlets take the command and just run with it without putting too much thoughts into the process.
UPDATE. A very basic example of explicit operation synchronization for your case (not that I like it, just to illustrate the point) would be to have a singleton service handling your operation with its main do() method declared as synchronized. Ideally, though, you would delegate database concurrency to your database and persistence layer (transactions, optimistic concurrency).
CORRECTION as per the servlets spec:
In the default case of a servlet not implementing SingleThreadModel and not hosted in a
distributed environment, the servlet container must use only one instance of a servlet class
per servlet definition.
In the case of a servlet that implements the SingleThreadModel interface, the servlet
container may instantiate multiple instances of that servlet so that it can handle a heavy
request load while still serializing requests to a single instance.
With that said, you would have only one instance of your servlet unless you use that single thread model marker.
1) No, only instance of servlet exists per server
2) No, each request is separate thread
Your server could shouldn't contain any instance variables (or) static variables, then synchronization won't be any issue because each thread will have it's own copy of local variables and execution sequence.
3) You can make servlet synchronized by prefixing synchronized the doGet(), doPost() methods are with the help of synch block. But it is bad practice.
Refer this SO Wiki link for complete discussion.
to synchronize a particular task, Let me suggest 2 ways.
use java synchronized block. You should consider what object is suitable for the lock object.
use database lock. Such as select * from xxx for update
Related
Can i use a singleton within a servlet to share information between diffrent session.
I know that only 1 instance Servlet is running at any time. Calling service method for each incoming request. But how about creating another Singleton class (for eg: ShareSingleton) which calls its getInstance() in the servlets Init() method. This ShareSingleton can carry data that needs to be shared between sessions/reqests.
Is it risky to use such an approach in servlets ?
First..see this for the best approach of singletons: http://javarevisited.blogspot.com/2012/07/why-enum-singleton-are-better-in-java.html
Second: Remember singletons are only single to the JVM. So..if you have more than one JVM running do not expect each singleton to have the same state.
Third: To be safe, I would instantiate the singleton from a listener of the servlet context.
see http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html
define a class in your web.xml and instantiate it there. Your singleton will be created when your webapp starts up rather than when n people hit the service method of your servlet at once.
Yes, you can. Note that the servlet container may use multiple instance of the Servlet object, so you'll have to make sure one object is shared amongst all these instances.
For example, you might do:
private static final Cache<String,String> = //cache
And then use the value in the cache if it's available, or otherwise update the cache with a newly calculated value. Note that the object that is shared must be thread safe.
I have a web application where multiple servlets use a certain amount of identical logic for pre-initialization (setting up logging, session tracking, etc.). What I did was to introduce an intermediary level between javax.servlet.http.HttpServlet and my concrete servlet class:
public abstract class AbstractHttpServlet extends HttpServlet {
// ... some common things ...
}
and then:
public class MyServlet extends AbstractHttpServlet {
// ... specialized logic ...
}
One of the things I do in AbstractHttpServlet's default (and only) constructor is to set a few private member variables. In this case it is a UUID, which serves as a session identifier:
public abstract class AbstractHttpServlet extends HttpServlet {
private UUID sessionUuid;
public AbstractHttpServlet() {
super();
this.sessionUuid = UUID.randomUUID();
// ... there's more, but snipped for brevity ...
}
protected UUID getSessionUuid() {
return this.sessionUuid;
}
}
I then use getSessionUuid() in MyServlet to provide for session tracking within the request. This is very useful e.g. in logging, to be able to sift through a large log file and get all entries relating to a single HTTP request. In principle the session identifier could be anything; I just picked using a UUID because it is easy to generate a random one and there's no need to worry about collisions between different servers, seed issues, searching through the log file turning up a match as a portion of a longer string, etc etc.
I don't see any reason why multiple executions should get the same value in the sessionUuid member variable, but in practice, it appears that they do. It's as if the instance of the class is being reused for multiple requests even over a long period of time (seemingly until the server process is restarted).
In my case, class instantiation overhead is minor compared to the useful work done by the class, so ideally I'd like Tomcat to always create new class instances for each request and thus force it to execute the constructor separately each time. Is it possible to perhaps annotate the class to ensure that it is instantiated per request? Answers that don't require server configuration changes are much preferred.
Failing that, is there a way (other than doing so separately in each do*() method such as doGet(), doPost(), etc.) to ensure that some sort of initialization is done per HTTP request which results in execution of a particular servlet?
It's as if the instance of the class is being reused for multiple requests even over a long period of time (seemingly until the server process is restarted).
Yes, that's exactly what will be happening, and what you should expect.
A servlet isn't meant to be a session - it's just meant to be the handler.
If you want to do "something" on each request, no matter what the method, you can override the service method, take whatever action, and then call super.service(). However, you shouldn't change the state of the servlet itself - bear in mind that multiple requests may execute in the same servlet at the same time.
Basically, what you're asking for goes against the design of servlets - you should work with the design rather than against it. You could modify the request itself (using setAttribute) to store some information related to just this request - but I'd probably do that at a higher level than HTTP anyway. (I'd try to make the servlet itself very small, just delegating to non-servlet-aware classes as far as possible, which makes them easier to test.)
This code is not threadsafe. The servlet container will generally create one instance of the servlet and all requests will use it.This means that the sessionUUID will be shared by all requests and will be continually overwritten.
If you need to keep this value on a per request basis, consider using a ThreadLocal object and putting the UUID in there.
It's as if the instance of the class is being reused for multiple requests even over a long period of time.
There is always one instance of a Servlet class at any given point in time per JVM. Hence instance variables are not thread safe in Servlet. Each request for the Servlet will be processed by a thread. Local variables declared inside the service(),doPost() and doGet() will be thread safe .
Hence you can move your logic to some other class , instantiate it inside the service methods and use it in thread safe fashion.You can even use ThreadLocal objects.
There is a provision to implement the SingleThreadModel ,it is deprecated, it is not only bad but ridiculous to do so.
Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
Better to implement a ServletRequestListener and put the logic there.
Referring to: Head First Servlets & JSP, page 204, third question:
Q. "The
effect of implementing SingleThreadModel is virtually
the same as synchronizing the service method. Both
can bring a web app to its knees without protecting
the session and context state."
What does this mean: "bring a web app to its knees without protecting the session and context state"? Are they saying that it's not enough thread-safe to implement the SingleThreadModel? Because even though only one thread at a time can be running at one servlet, this doesn't stop other servlets from accessing and mutating the context/session scoped variables? If a Servlet implements the SingleThreadingModel, then why would you need to protect session state? It only allows one thread at a time. Even if you open up a new browser window, the servlet wouldn't allow you to make two requests, I think. Maybe they mean that different Servlets with one thread at a time could still corrupt the context/session state if they don't synchronize on that state?
And why are class (static) variables not thread-safe? Because all threads can access and modify (corrupt) that value?
It's still a little vague to me.
Referring to: Head First Servlets & JSP, page 204, third question:
Q. "The
effect of implementing SingleThreadModel is virtually
the same as synchronizing the service method. Both
can bring a web app to its knees without protecting
the session and context state."
What does this mean: "bring a web app to its knees without protecting the session and context state"? Are they saying that it's not enough thread-safe to implement the SingleThreadModel? Because even though only one thread at a time can be running at one servlet, this doesn't stop other servlets from accessing and mutating the context/session scoped variables?`
This is correct.
If a Servlet implements the SingleThreadingModel, then why would you need to protect session state? It only allows one thread at a time. Even if you open up a new browser window, the servlet wouldn't allow you to make two requests, I think.
That is incorrect. You could have another tab, another window or whatever. You might not be able to access the same Servlet at the same time, because you might be blocked, but you could access another Servlet that also accesses the same Context or Session. And, according to the API, it is allowable to have multiple instances of the same Servlet serve multiple responses in different threads (the only restriction is that one instance can't server multiple threads).
Maybe they mean that different Servlets with one thread at a time could still corrupt the context/session state if they don't synchronize on that state?
And why are class (static) variables not thread-safe? Because all threads can access and modify (corrupt) that value?
There is nothing inherently more or less thread-safe about static variables than instance variables. But you have to understand how the values are protected and how the SingleThreadModel is implemented. If the SingleThreadModel is implemented by allowing multiple instances of the Servlet, each stuck on a single Thread, then the static variables would be shared among all instances and therefore accessible to their threads as well.
Regardless, I would think you should never use (non-final) static variables in the Servlet class because you don't control the Servlet's life cycle. It can be created, destroyed, and recreated as the container demands. So a value you put in the static variables may not be there when you next try to access it. And you should never use the SingleThreadModel because it is inefficient and doesn't really do its job, and it has been deprecated for a long time. So you definitely should not use them both together.
bring a web app to its knees
Because the access to the service() method of the Servlet will be synchronized . This can be implemented in two ways , (1) block other request threads till the current thread completes execution of the service() , (2) Create new instance of the Servlet (or maintain a pool of Servlet instance) in the Container and each request invokes the service() of a separate instance. Both are resource intensive and non performant.
without protecting the session and context state
Because even though you synchronize access to the service() method of your particular Servlet which implements the SingleThreadModel . The access to the session and context are not synchronized . Code other than your Servlet are free to access HttpSession or ServletContext attributes.
Are they saying that it's not enough thread-safe to implement the SingleThreadModel?
Yes , even the class variables may not be thread safe , if the Container implements the model such that each thread uses a free Servlet instance from the pool.
Because even though only one thread at a time can be running at one servlet, this doesn't stop other servlets from accessing and mutating the context/session scoped variables?
Absolutely.
If a Servlet implements the SingleThreadingModel, then why would you need to protect session state?
To protect the data stored in the HttpSession . Because even though only one thread at a time can be running at one servlet, this doesn't stop other servlets from accessing and mutating the context/session scoped variables.
class (static) variables not thread-safe
Because it is shared by all instances of a class.
And why are class (static) variables not thread-safe? Because all
threads can access and modify (corrupt) that value?
Correct. If a member is static, one thread can set a value and another thread can set differently. As static is shared variable, the value set by first thread will be the same for another thread also.
Q. "The effect of implementing SingleThreadModel is virtually the same
as synchronizing the service method. Both can bring a web app to its
knees without protecting the session and context state."
Even if you make some servlet implement SingleThreadModel, it will stop only those thread to executly simultaneoulsy which are trying to access that servlet. It can't stop all other servlets which do not implement SingleThreadModel from accessing context and session attributes. This is because context attributes are available all over the web application and anyone resource can access them and modify them.
I am running into a situation where I use ThreadLocal static variable to hold a bean that contains various metrics values from different classes during the lifecycle of the request. In a filter I create the bean and set it in a thread local variable and remove it from the thread local variable in the same filter after request has been processed. What I am running into is that the bean containing values from other requests! The only explanation for this is the thread being shared to process multiple requests at the same time. So the question in the title.
While one thread will generally process a single request (speaking about tomcat, for sure), the thread may process multiple requests over time but not w/o finishing the existing request, unless using include/forward alikes.
I'd VERY strognly recommend you to use attribute (setAttribute()) of the said request w/ your bean and use it for profiling. If you can't provide the request to various methods... well you are stuck w/ the ThreadLocal [which is not so bad solution].
Alternatively you can post the code how you install/remove the threadLocal bean.
Keep in mind that you have to to some managing the of that bean as well (it will not be available outside the request).
Edit: forgot to ask: do you use try/finally calling doFilter(...)?
the code should be like that
installBean();
try{
chain.doFilter(req, resp);
}finally{
Bean b = deinstallBean();
useTheMetrics(b);
//potentially, process exception, etc
}
It could also be that your filter is not always called in the sequence you expect it to be. Threads are reused to process multiple requests one after another, so if the removal of the value in the ThreadLocal does not happen, it will still be there when the thread processes its next request.
Yes, you can assume that a single thread will process each request.
Use a finally block to clear (set to null) the ThreadLocal in the filter after processing the rest of the chain. That will prevent data from previous requests from being mingled with the current request.
In the Tomcat container, do all the filters associated to a servlet and the servlet itself use the same thread? i.e, will doFilter() be run in the same thread as a servlet's service() method? Thanks in advance.
I suspect the question is more: Can I use ThreadLocal objects to pass data between filters and to servlets? In which case the answer is, absolutely. App servers do this themselves to track security, transaction, connection and other request information.
Just make sure you clean out your ThreadLocal in a finally block in the same code that sets the ThreadLocal.
As already noted by other, the servlets themselves may or may not be synchronized, but that is orthogonal to the concept of thread state; i.e. how many threads execute against object foo vs. can I put state in the thread and have it seen by object foo. The answer to the second question is always yes.
The only time the answer would be 'no' is if you made use of any asynchronous communication:
Dispatched the call via AsyncContext
mixed in EJBs and started making use of #Asynchronous or the TimerService
These involve the app server starting new threads not associated with the original request thread so any ThreadLocal state will not travel with the new thread. It is also why those APIs do not allow security and transaction context of the caller to be propagated to the method invoked as the caller and method are in different threads.
Advanced note, InheritableThreadLocal typically does not work as async calls are typically done by the server against a thread pool rather than creating child threads of the caller thread.
Yes, each request is performed in a single thread, including all filters and the target servlet.
Yeah, each request is performed within a single servlet instance.Servlet container receives each request and start a new thread which contains the HttpServletRequest and HttpServletResponse. This thread process the request in the service method of the servlet instance and will be destroyed as soon as the service method completes.