We Keep Coding

How Multi-User Java Applications Really Work

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.

Servlet instances in a web container

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.

How many instances are created for a HTTP servlet

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.

Singleton use in different thread

I have a remote service and an, object (singleton). When I call the singleton class from UI thread and remote service I get 2 objects. Can anyone help me?

If you have a remote service then you have 2 completely separate processes. Each process has its own virtual machine. Therefore, your singleton class is instantiated once in each process.
If you really need a single then think about whether you really need a remote service. If you can implement your remote service as a local service then that will solve your problem.
If, on the other hand, you really need a single instance that is shared across the 2 separate processes, then you will need to instantiate the singleton only in the remote services process and access it via remote calls from the UI process.

Thread Local recommendations in heavy back-end mid-tier server application

Is it recommended to use ThreadLocal to store a Thread Context?
I am building a backend server application where there are typical services that I need to run.
Note: We are not building this over a SOA architecture.
Before the start of each service I need to give it a state which has some Service Contex which is variable map to work up on. This variable map is shared when services are running parallelly.
Now for example a service needs to check weather it has to be halted or timed-out based on some thread related parameters.
Question: Is it a good approach to keep the thread context inside thread local and then building api's over service context to access parameters over these variables.
This would help me to hide the complex behavior and it wouldn't open up my internal things.
Thanks,
Aditya

It looks like your server application framework ought to provide you with the means to implement this functionality in a simpler way - unless you are implementing your own framework.
Now for example a service needs to check weather it has to be halted or timed-out based on some thread related parameters.
An EJB container provides this kind of functionality. EJBs also provides a session context and the means to ensure that the context can be restored if execution is transferred between threads (by passivation + activation).

You can use ThreadLocal quite freely but you must define your thread model cleanly (see if you have any control on the thread creation)... also keep in mind that assuring the state stored in the ThreadLocal might not what you expect, if you are relying on any clean-up code.
Also: do use (cant stress more) WeakReference for anything that your code is not directly responsible.