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.
Related
I have 2 .ear file under a single domain (eg : abc.ear, def.ear). How to communicate between them?
You can use Remote Method Invocation. Usually the beans of your application will be registered in the application server upon deployment. With the correct name you can then use a lookup to get that remote bean (remote meaning a bean from the other .ear). From there on you an use that bean as if it was a local one.
I am sure you can find a good tutorial on RMI for your specific application server.
EDIT: I just noticed that communicate is a rather broad term and my interpretation might not fit what you want. RMI is used to call methods and objects. If communicate means to transfer data only you could also use a middleware like Java Message Service to send messages to the other .ear.
This question is rather broad I'm sure but I believe I don't fully understand how multi-user applications work and I would like some clarification on the subject or an idea of where to look for more info (not sure I know what to search for)
I understand the development aspect, but once you deploy the code to the server, how does it handle multiple users? For example, if I have a singleton class then that class will only ever be instantiated on the server once ... but the class will need to be used by multiple users simultaneously which means that the variables inside the class need to potentially be different for each user, how is this achieved behind the scenes?
Is it just the concept that each different user will access the class on a different thread? and if so, wouldn't that mean the whole application needed to be thread safe?
Let me explain this straight and will start from this point
once you deploy the code to the server, how does it handle multiple users?
----> Yes every web application or enterprise application should be deployed in server, web application on web server like tomcat enterprise applications on WebSphere. Every server will have servlet container with multiple number of threads (by default 200 in tomcat) each input request will be handled by individual thread (so multiple request can execute concurrently)
if I have a singleton class then that class will only ever be instantiated on the server once
---> yes singleton class will have only one instance per server, so multiple threads can access same object concurrently and which may cause data inconsistency, which is developer responsibility to take care of this responsibilities. The main problem with singleton class will be class (instance or static) level variables with setter methods because two threads can access same object concurrently and change the values, In the real time scenario singleton design pattern is used for Connection Pool object
Note Local variables are best in multithreading because every thread has its own stack, and they cannot be access by any other threads.
but the class will need to be used by multiple users simultaneously which means that the variables inside the class need to potentially be different for each user
---> To save request properties into object Models or POJO will comes into picture, these are prototype for every request new object will be created.
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
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.
I'm new to both J2EE and WebLogic. I'd trying to determine the best way to implement a non-distributed cache (one cache per application instance) in a Java Web Services application running on WebLogic 10.3. I need to cache several different POJO's.
There will be multiple WebLogic instances running on each server in a cluster. When reading about ServletContext and InitialContext, I was a bit confused. I believe ServletContext is instance specific, but I can only access it from a Servlet, correct? I will need to access to the cache in separate threads so I'm not sure if this is possible outside of a Servlet.
I was reading a bit about JNDI, but it seems to work at the server or cluster level and not for each WebLogic/application instance.
Can anyone provide me with a suggestion and a code example to initialize, access, and destroy a cache of Java POJO's?
Thanks!
Leon
Here is an example on how to implement a method cache with Spring and EHCache:
http://opensource.atlassian.com/confluence/spring/display/DISC/Caching+the+result+of+methods+using+Spring+and+EHCache
The cache will be local if configured as in the example.
I am using this method in a web service client library to cache the results of a frequently used service that has nearly no update to its data.