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.

Should I keep an OSGi ServiceTracker open, or close it after use?

What is the best practice for using an OSGi ServiceTracker in a BundleActivator? I have seen examples on the web that open a tracker in the start method, store it in an instance variable, and close it in the stop method, keeping it open for the life of the bundle. Is this appropriate? I have been writing code that opens the tracker whenever I need it, gets the service and uses it, then closes the tracker. Of course, this requires storing the BundleContext itself in an instance variable if I want to use it at a later time. Since I have to store one or the other, it may not make much difference which I store.
In a related question, if I do open the tracker each time I need it, is it necessary to keep it open while I am using the service that I got from it, or can I open the tracker, get the service, close the tracker, then use the service? I see no reason that I could not close the tracker before I use the service.

Services come and go – your responsibility as an OSGi developer is to use services only when they have been published by their bundle, and more importantly to release them when they are unpublished. If you continue using a service after it has been unpublished, you risk unpredictable errors occurring. At the very least you will cause the heap space associated with that service instance to be pinned in memory, which undermines OSGi's ability to dynamically install and uninstall bundles.
So, you ask whether you should close the ServiceTracker before using the service: my answer is NO. ServiceTracker acts as a "smart pointer" to the current service, and it manages all the listeners etc in order to be notified when the service goes away. If you close the tracker, then you are no longer kept up to date with the state of the service, so how do you know if it is still valid?
The ideal pattern for using a ServiceTracker -- assuming that the tracker remains open throughout -- is as follows:
{
Service svc = tracker.getService();
svc.doSomething();
}
// 'svc' is now forgotten, and may be garbage collected
That is, when you call getService() on the tracker you obtain an instance of the actual service, but you should use it quickly and then forget it as soon as you can. You absolutely must NOT store the result of getService() in a field and hold on to it for a long time.
As for whether you should open and immediately close the tracker only when needed – NO, there is absolutely no need to do this. An open tracker does not consume any significant resources, it simply means it is registered as a listener so that it knows when services come and go. In fact it is inefficient to repeatedly open and close the tracker since each time you open it, it has to synch itself against the current state of the service registry. This is why the pattern you have seen in examples is usually to open the tracker during bundle activation and keep it open... it's the best pattern.
Incidentally there is also no need to explicitly close a tracker in your BundleActivator.stop method. All resources associated with your tracker will be automatically cleaned up when your bundle stops. The only reason to explicitly close is if you have several trackers and/or service registrations, and you want to control the order in which you clean up.
Now having said all of the above, I'm going to chuck in a hand grenade: PLEASE STOP USING ServiceTracker! It is a very low-level utility, that is only very rarely required, and then only in "plumbing" or infrastructural code. Most of your application should be built with a higher level of abstraction. I strongly recommend using Declarative Services, which is much, much easier than messing around with ServiceTrackers.

The best practice for the Service Tracker is to use Declarative Services.
For the experts: There are some highly specialized cases where the Service Tracker is useful (and unmissable!) but if you have to ask this question then the Service Tracker is not for you. The Service Tracker is a very low level way to work with services used by middleware like Declarative Service implementations, Blueprint implementations, etc.

In case you wanted to open a tracker just for a service call you do not need tracker at all. All you have to do is getting the service via bundleContext and unget it when you are done.
ServiceTracker is not only good for calling a service but you can also call waitForService method so your thread will wait until a good service is available.
In case you use a service tracker and you call getService() to get the service object every time you may not call the same service. Service Tracker tracks every service that meet the filter criteria by default so if the service you used last time is unregistered next time another service will be given to you.
If you subclass from service tracker or write a ServiceTrackerCustomizer you can catch the service tracking events. E.g. you can create a logic that you provide an own service object each time a service is registered that meets your requirements. Also you can specify which services should be tracked (you return null in addingService than that service will not be tracked).
In short:
In case you want to call a service only once or twice (for example when your bundle starts or it stops) you can simply get a service via context and unget it
In case you want to call a service many times during your bundle is active or you want to create custom logic based on service availability events, use a service tracker
If you choose the first option, Never keep a service object for longer period in a member variable! In case of the first option you should unget the service as soon as you do not need it anymore. It is the same with service tracker. Call each time the getService method instead of keeping it in a member variable of your class as it might be unregistered by the time you need it again.
Other OSGi experts are here at stackoverflow (people who designed OSGi) so they may give more specific answer.

I think ServiceTracker is useful for using Services both inside the method BundleActivator.start() and inside the method activate() of Components.
The goal to use them at initialization time is to avoid the dead-lock that could be caused when we use Services at bundles that are being initialized too.
Is it a case in which ServiceTrackers are recomended or is there any other better pattern based on DS for initialization time?

JAX-WS web services threading model

(1) Okay I am pretty confused about the threading model of JAX-WS Java web services. I read they are not thread-safe. How are they supposed to serve multiple parallel requests then? Given that its always known (mostly) they are going to get called from multiple clients at the same time.
(2) And does the app server create a new instance of web service for each request (like it maintains a pool of stateless session beans, assigns one out for a request and once the request completes, it is returned to the pool). can you configure that pool size in app server console (GlassFish or JBoss or WebSphere).
(3) And I also found out about #Threadsope annotation here which creates new thread per request..
http://jax-ws-commons.java.net/thread-scope/
Is that a good option? I am sure people are solving the thread-safety and parallel requests issues in some other standard way - please advise.

An application server contains a pool of beans.
When working with stateless session bean, it is not guaranteed you will get the same instance across working with the session.
However, since as I mentioned, the beans are managed by a pool, holding a state in them, is a bad idea.
I don't think that EJB beans have anything to do with what your need, though.
Pay attention that in the example you provided, Both DataService and the connection are created per request. This is a bit expensive.
I would consider using the ThreadLocal API only for the connection, and have it obtained from a connection pool.
You can implement these on your own, by reading about ThreadLocal and by reading about DB connection pools.
To conclude - I don't think EJBs are relevant here.
Don't hold both your service class and the fields at the thread local, but only the necessary fields you will allocate per request. (in the example you showed - it's the connection)

ThreadLocal safety in Weblogic threadpool

I'm writing an app which uses MDBs, EJBs and needs ThreadLocal to pass and log a variable across multiple EJBs and Helper classes until the transaction is complete.
The flow is
Starting with MDB onMessage()
-> some business delegate EJBs
-> some helpers
Question:
This app runs within Weblogic and Weblogic re-uses Threads from within it's ThreadPool. So is there a possibility of data corruption across threads? Is the solution to use ThreadLocal.remove() safe enough?
Is there an alternative to ThreadLocal other than passing around the Object as a parameter to all methods?

WebLogic does not reset user set ThreadLocal variables when the thread is returned back to the pool - the user is responsible for managing them. When such threads are reused, its likely they will interfere. You may run into memory leaks since the thread local reference isn't cleaned up. You can safely reset your thread locals prior to returning the thread back to the container. The ThreadLocal.remove() call should clean it up (ensure that its done in a finally block)
Note that if any async or rmi calls are involved, your thread locals will not propagate. You may want to consider the WebLogic WorkArea feature which allows context propagation across threads, clients & servers. More details can be found at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13706/context.htm#i1058690

You can't reliably use a ThreadLocal in the EJB tier. Even if your code seems to 'work' now, what happens if someone deploys one of your beans remotely? From EJB Restrictions:
Why is thread creation and management disallowed?
The EJB specification assigns to the EJB container the responsibility
for managing threads. Allowing enterprise bean instances to create and
manage threads would interfere with the container's ability to control
its components' lifecycle. Thread management is not a business
function, it is an implementation detail, and is typically complicated
and platform-specific. Letting the container manage threads relieves
the enterprise bean developer of dealing with threading issues.
Multithreaded applications are still possible, but control of
multithreading is located in the container, not in the enterprise
bean.
If you need to share state, you should pass it in to the EJB method as a parameter. Is there a reason this approach won't work for you? Another option would be to temporarily dump it into a transaction enlisted database or cache.

#JoseK: though I have not tried what you described in your issue, but here are my thoughts:-
Both MDB and Session beans are thread-safe. It means let us say if there is pool of 10 beans, only 10 requests will be handled simultaneously. Other requests would be queued for their turn. So one running thread local data should not interfere with other thread.
If you confident to use always local EJBs in future also, then I don't really see any issue in using thread local data. Because you are not really creating threads.
Though weblogic provides thread from thread-pool but that thread is given dedicately to each request flow, I don't think its local data should become corrupted ever.
As I said I have not tried myself, what I would try is:-
In MDB layer(your first layer), do Thread.getCurrentThread.setName(name)
and in subsequent layers print thread names like Thread.getCurrentThread.getName)
Perform multiple runs with different size of ejb pool, thread pool. Give a different thread name to each request flow. Try running multiple requests same time. And see if you ever get thread name mixed.
5.Having said above, to keep things simpler and furture remote EJB support, I would also pass CallingContext Interface to each layer.

Need help with java web app design to perform background tasks

I have a local web app that is installed on a desktop PC, and it needs to regularly sync with a remote server through web services.
I have a "transactions" table that stores transactions that have been processed locally and need to be sent to the remote server, and this table also contains transactions that have retrieved from the remote server (that have been processed remotely) and need to be peformed locally (they have been retrieved using a web service call)... The transactions are performed in time order to ensure they are processed in the right order.
An example of the type of transactions are "loans" and "returns" of items from a store, for example a video rental store. For example something may have been loaned locally and returned remotely or vice versa, or any sequence of loan/return events.
There is also other information that is retrieved from the remote server to update the local records.
When the user performs the tasks locally, I update the local db in real time and add the transaction to the table for background processing with the remote server.
What is the best approach for processing the background tasks. I have tried using a Thread that is created in a HTTPSessionListener, and using interrupt() when the session is removed, but I don't think that this is the safest approach. I have also tried using a session attribute as a locking mechanisim, but this also isn't the best approach.
I was also wondering how you know when a thread has completed it's run, as to avoid lunching another thread at the same time. Or whether a thread has ditched before completing.
I have come accross another suggestion, using the Quartz scheduler, I haven't read up on this approach in detail yet. I am going to puchase a copy of Java Concurrency in Practice, but I wanted some help with ideas for the best approach before I get stuck into it.
BTW I'm not using a web app framework.
Thanks.

Safest would be to create an applicationwide threadpool which is managed by the container. How to do that depends on the container used. If your container doesn't support it (e.g. Tomcat) or you want to be container-independent, then the basic approach would be to implement ServletContextListener, create the threadpool with help of Java 1.5 provided ExecutorService API on startup and kill the threadpool on shutdown. If you aren't on Java 1.5 yet or want more abstraction, then you can also use Spring's TaskExecutor
There was ever a Java EE proposal about concurrency utilities, but it has not yet made it into Java EE 6.
Related questions:
What is the recommend way of spawning threads from a servlet?
Background timer task in a JSP web application

Its better to go with Quartz Scheduling framework, because it has most of the features related to scheduling. It has facility to store jobs in Database, Concurrency handling,etc..
Please try this solution
Create a table,which stores some flag like 'Y' or 'N' mapped to some identifiable field with default value as 'N'
Schedule a job for each return while giving loand it self,which executes if flag is 'Y'
On returning change the flag to 'N',which then fires the process which you wanted to do