问题
Are there are any thread safety related benefits of exposing a web service as a stateless session bean?
(Correct me if i am wrong) but I think web services are not thread safe and like Servlets only one instance of a web service class is created by the server (not one instance per request).
What I don't know whether they are assigned from a pool of beans like stateless beans are - by the app server. I am trying to find if I use @Stateless annoation with a web service that's already annotated with @WebService annotation- will that force the app server to start assigning them from a pool for each incoming request. That way I know for sure I will one separate instance created for each incoming request?
回答1:
Introduction
The number of instances used by the web service endpoint depends on the framework you are using.
If you use a simple endpoint (i.e. JAX-WS with Apache CXF or Spring webservices) you will have a single service instance for all the threads/requests (as you said, Servlets). So, by definition this kind of services are meant to be stateless. But if you need to add some state to the service, you can do it, but is up to the developer to make the service thread safe.
When you use EJB you have more flexibility: if you use stateless beans you will have a pool of instances to manage all the request (if your poolSize=1 you get the same behaviour of Apache CXF). Again, you can add some state to a stateless bean, but make it thread safe is even harder because you have a pool of instances to manage. But if you need an state you can use an stateful bean to have a framework that make your life easier regarding thread safety.
Some hints regarding service states
If you do not keep an state in your service your web service is thread safe. In other words, an stateless service if thread safe by definition.
If you need some state that should be share by ALL the thread/request you can add some state to an stateless service (JAX-WS or a Stateless session bean with poolSize=1) but you need to make it thread safe, adding sycn blocks (please, do not sync your @WebMethod). IMPORTANT: In theory (and in practice), you should NEVER add an state to a stateless session bean, because the pool can destroy/create instances when it "wants to".
If you need to keep an state that will be use only by the current thread/request you can add some state to a stateless service using ThreadLocal variables, or more easily using stateful session beans.
Now, finally, answering your question
- Stateless session beans are thread safe if and only if you make them thread safe: they should not have an state :-)
- The only different between a classic web service and a stateless session bean web service if that the first one will have a single instance, and the second one will use a pool of instances. If your poolSize=1 you get the same effect, but in theory, the pool can destroy your instance when it "wants to".
Hoping it helps,
来源：https://stackoverflow.com/questions/11478756/any-thread-safety-benefits-of-exposing-a-web-service-as-a-stateless-session-bean