A web container will typically create a thread to handle each request. To ensure that a servlet instance handles only one request at a time, a servlet can implement the SingleThreadModel interface. If a servlet implements this interface, no two threads will execute concurrently in the servlet’s service method.A web container can implement this guarantee by synchronizing access to a single instance of the servlet or by maintaining a pool of web component instances and dispatching each new request to a free instance.
Could someone clarify the bolded part of the above paragraph ?
Doesn't each servlet would have only one instance of it in a web container?
Doesn't each servlet would have only one instance of it in a web container?
No, that is not always true. The web container manages the lifecycle of servlets (it is responsible for creating and managing instances of servlets). The Java EE specification does not guarantee that there will be only one instance of your servlet class, so you should not write your servlets in a way that depend on this.
As the description explains, the web container might make multiple instances of your servlet class to efficiently and concurrently handle requests if your servlet implements SingleThreadModel.
It is better to write your servlet in such a way that it does not need to implement SingleThreadModel - write your servlet code in a thread-safe way.
Related
I have a JSP/Java web application which uses Jersey on a Tomcat server and this app must be live for months/years executing threads and maintaining live some objects.
What would be more efficient and safe? to use static methods on the jersey calls or to use instanced objects initialized on ServletContextListener contextInitialized() ?
Why?
I was trying to understand the difference between EJB and Servlet (I know both are conceptually different, EJB is a piece of Java Code with some rules and Servlet is something that accepts and processes HTTP requests) But I found that one of the difference between the two is also:
Ejbs allows Remote Accessing.
Servlet/jsp's does not allow remote accessing
I do not understand the above difference. Why an EJB can be remotely accessible and Servlet not.
Servlet responds to http request (normaly) note that a JSP is transformed to a servler. A EJB it's totaly diferent, EJB define your business model.
It seems you are confused about what remote accessing is, it means that you can have a EJB deployed in a different server running in a different JVM and that your servlets can access it.
In the other side you can have local EJBs which run in the same server has the rest of your webapp and in the same JVM as your servlets and jsps. Depending on whether you EJB is local or remote the implementation differs in some little aspects (in remote EJBs you need to create an interface and other things, I won't enter in details, I'll add a link about this).
If you want to understand what's the difference between servlets, jsps and ebjs, you should understand what MVC (Model View Controller) is. Normally Controller is defined by servlets, which receive the http request from the client and delegate the actions that they do in EJBs and JSPs. The View is defined by JSPs ( I assume you already understand what they are). And EJBs are the Model, they define your business model, they don't serve http requests, they just perform simple actions over your "model" like update/select/insert data in your database, and many other things.
See more in:
https://docs.oracle.com/javaee/7/tutorial/doc/ejb-intro.htm#GIJSZ for EJB
Also I recomend you the following two books:
Head First Servlets and JSP http://shop.oreilly.com/product/9780596005405.do
Head First EJB http://shop.oreilly.com/product/9780596005719.do
I am going through the book for "Java Web Services: Up and Running, 2nd Edition" and came across a statement that says:
A web server such as Tomcat can instantiate arbitrarily many instances
of a servlet, although the number is typically small (e.g., 1 through
4). The web server itself makes the decision.
So it means if I create a servlet then the server can create more than 1 instance but this is in contradiction to the explanation given in many posts for example if I check in this post : "10 clients requests for a Servlet.How many servlet instances are created" then it clearly states that:
Only one instance of servlet exist (per classloader) , and each
request will be served on its own thread
So please help me in understanding this, does a server can create more than 1 instance for a servlet?
The Servlet Specification states
For a servlet not hosted in a distributed environment (the default),
the servlet container must use only one instance per servlet
declaration. However, for a servlet implementing the
SingleThreadModel interface, the servlet container may instantiate
multiple instances to handle a heavy request load and serialize
requests to a particular instance.
In the case where a servlet was deployed as part of an application
marked in the deployment descriptor as distributable, a container may
have only one instance per servlet declaration per Java Virtual
Machine (JVM). However, if the servlet in a distributable
application implements the SingleThreadModel interface, the container
may instantiate multiple instances of that servlet in each JVM of the
container.
So it depends how you are deployed.
As suggested in the comments, SingleThreadModel has been deprecated for a long time.
by default servlets are intrinsic multithreaded. so only single instance be created and will be accessed by multiple threads.
I'm creating a web application with servlets and I need a thread changing a number constantly and when a client do a request it gets the current number.
I tried creating a class with the main method and from there start the thread, then from the servlet get the instance where the thread is running (can this be possible?), but the application never enters to the main method.
Any suggestions?
Thanks
Servlets run in a web container and the web container's main method is out of your control.
If you want to perform any startup operations, then the servlet framework provides context listeners that can be registered with the framework. These listeners are called when your web application starts.
Alternatively, if you want to perform some operation on each incoming request or outgoing response, then you can use servlet filters
You should have a scheduled task that runs on your webserver, that updates that number. There is no "main" method (as in application entry point) in web applications, since each servlet is an independent entry point.
How do I pass objects from non-GWT server-side code (e.g. regular server code) to the GWT "servlet" (still server-side code), specifically a RemoteServiceServlet?
My GWT server-side code consists of RPC-type RemoteServiceServlets to which I can't seem to get a reference so I can't pass in my real/fake object in testing mode or add servlet attributes. I can't see any way to simply pass objects in (dependency-injection style) as I have no access to the Server object as GWT seems to instantiate it deep within its internals, so what are my options?
P.S. I don't want to use a full-blown DI framework such as GIN/Juice - I find them to much magic. I just want a way to access the instance of a GWT servlet and pass stuff to it.
Let me start out by saying, if you haven't already, I highly recommend watching this Google I/O presentation on GWT Architecture best practices. I found it very useful and it's where most of the following came from.
What I did was create an abstract "dispatch" servlet that extends GWT's RemoteServiceServlet. Every module I have has only one service (that extends my abstract dispatch service) with which I register a set of request handlers. All GWT service calls for a given GWT module come into that module's dispatch service, which looks at the type of request and dispatches it to the appropriate request handler. The request handlers, in effect, handle the work that previously resided in the service servlet. Besides making your life easier by having fewer servlets to register in your web.xml (not to mention avoiding the extra interfaces GWT requires), you can more easily control the dispatcher object that handles all the actual dispatching. You can, for example, pass whatever real/mock object you like into these request handlers since you, and not the web container, are responsible for instantiating them.
And though I rolled my own, the gwt-dispatch project exists for this very purpose.
Hope this helps.
Servlet containers are designed to not allow direct access to the servlets that they host; that's why you've found it difficult to get any kind of handle to a servlet.
Rather, refactor the code that is currently in your servlets into separate request-handler classes, and have your serlvets call into them.
For testing purposes you can hook your testing framework, or your client code, to the request-handler classes directly. That's how people generally solve the problem you've run into.