3

(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.

informatik01
  • 16,038
  • 10
  • 74
  • 104
Robin Bajaj
  • 2,002
  • 4
  • 29
  • 47
  • This is the question I am trying to find answers for. I got some information (with little clarity). What I learned is, Server creates single instance for webservice (like servlets), so they (Services) are not thread safe. So, while coding itself don't keep any thread specific data as either instance variable/static variable. – kosa Jul 13 '12 at 18:27
  • @thinksteep I have a response for you .. check this out.. hope it answers some of your questions.. http://stackoverflow.com/questions/11478756/any-thread-safety-benefits-of-exposing-a-web-service-as-a-stateless-session-bean/11494336#11494336 – Robin Bajaj Jul 15 '12 at 19:27

1 Answers1

1

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)

Yair Zaslavsky
  • 4,091
  • 4
  • 20
  • 27
  • Thx for your response ... Can you address (1) and (2) as well above ...They are questions about web service life cycle and I haven't found any good documentation that answers those questions .. – Robin Bajaj Jul 14 '12 at 00:12
  • 1
    Once again, I think that this is a bad apporach, and you should go for stateless behavior. I develop less with JAX-RS. From what I saw in the documentation, you can create using @ThreadScope an inststance of your service per request thread, but this is bad. One more note - if you find I give you help, feel free to upvote my answer, I will appreciate it. – Yair Zaslavsky Jul 14 '12 at 07:02
  • Thx @zaske. I would appreciate if you explain 'why' you think it's a bad idea... You just made a statement without explanation to support it...:) – Robin Bajaj Jul 14 '12 at 15:39
  • Also @zaske I fail to understand how a thread per request is 'not' a stateless approach - your response seems to suggest so... – Robin Bajaj Jul 14 '12 at 15:48
  • I am still looking to get explanation or reference links for (1) and (2) above. – Robin Bajaj Jul 14 '12 at 15:49
  • I was misunderstood - Of course thread/Service object per request is stateless. What i'm saying is that you can acheive that with a single object that serves all the request - just don't hold private fields in it. – Yair Zaslavsky Jul 14 '12 at 20:32