Sun's tutorial: "When a client invokes the method of a stateless bean, the bean's instance variables may contain a state, but only for the duration of the invocation"
Stateless session beans can be shared by multiple clients between method invocations, but only one client at a time may call one of the methods.
If you only have three or four simultanious clients this probably wouldn't be a huge problem. Clients 2-4 could block while Client 1 was executing a method, and then their calls could be executed serially. Client 4 sees a small delay.
If you have thousands of simultanious method clients (although you'd have an extremely hard time purchasing a computer that can handle that many threads at once -- look up thread pooling) then you can't really ask method Client 425 to wait until Clients 1-424 have finished their calls. One the other hand, creating 424 seperate objects would be a waste of memory and would involve some heavy object-allocation costs.
The best solution is a blend of the two. Create a Method-Ready pool for the stateless session beans and use an intellegent management algorithm to maximize performance. One option is to impose a maximum size on the pool (which is similar to saying that only N clients may simultaniously call methods on the bean). The N+1th client will block until another client finishes.
Another possible option would be to wait a few milliseconds before adding a new object to the pool for a new client -- it's possible that an old client's method call will finish very quickly and thus serial execution is sufficient for that particular case. The next call may block for more than a few milliseconds and then get its own new object.
The possibilities are limitless. You can mix and match all kinds of intellegent load management algorithms. Fortunately, you and I don't have to know what the container is doing. Somehow it all "just works."
Originally posted by Learn Java:
Will my application crash if i have 1000s of clients ( threads?) executing methods on 1 stateless session bean?
As I mentioned early, read up on thread pools. When 1000 people simultaniously connect to a website that uses traditional technology, the server reaches a limit on the number of threads allocated. Let's say that limit is 15. It's like having 15 checkout counters at the supermarket and 1000 people waiting on line (and in fact, this situation is bascially identical to the N limit I mentioned above).
Some servers are now using non-blocking IO, which means that they can really handle 1000 simultanious clients in one or three threads, but that can't really be done with script-based (
JSP, ASP, CGI, etc.) model of most application servers.
If you're really nerdy and you're interested in high-concurrency computing, Matt Welsh's thesis (available under the "Papers" section
here) is an interesting read.
[ February 16, 2003: Message edited by: David Weitzman ]