Hi All, I understand Java and i was just trying to get some insight into J2EE,EJB.I was reading about stateless session beans. I guess stateless session beans participate in "object pooling" as well? My Question is say i have 10 clients, now do i need "n" stateless session bean instances / one to serve them. Why can't we have just one stateless session bean to handle all the clients. i guess in a CPU only 1 thread can execute @ a given point of time. How can i improve performance by having more objects? Will my application crash if i have 1000s of clients ( threads?) executing methods on 1 stateless session bean?
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 ]
Originally posted by David Weitzman: 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. [ February 16, 2003: Message edited by: David Weitzman ]
thanks for the explanation. The thread pool concept made lot of sense since the OS inherently must have a limit on the number of threads it can support. But the object pool is something that am not able to understand :-( Say I have 2 business methods defined in the stateless session bean class BusinessOperation, as described in Monson haefel's book, createReservation(), createCustomer() and i dont have any instance variables in the BusinessSessionBean class. Now if i have a limit of say 15 threads , why can't i have all of them execute the business methods on the same instance of BusinessSessionBean instead of on multiple session bean instances? What do i gain by executing methods on different instances / by allowing only one client to execute a call on one of the methods at a given time. w'd'nt every thread get it's own copy of the variables declared in the business methods and execute as and when the OS schedules the operation?. I w'd really appreciate it if you c'd explain the idea behind object pools for session beans with this example. I know that am missing something here, but since i don't understand it, am posting this question here. thanks, sangeetha
i dont have any instance variables in the BusinessSessionBean class .... I know that am missing something here
You aren't missing anything! In this case, you don't need object pooling. A very intellegent container wouldn't pool that object at all (although it might be tricky to detect which classes/methods don't use instance variables -- a container could have it's own special way of marking "completely-and-utterly-Stateless beans" in configuration files). The EJB specification allows the use of instance variables during method calls to provide maximum flexibility to programmers. Very often that flexibility will be more than you need. Anyway, it's just a feature (or, arguably, a flaw) of the EJB specifications. [ February 16, 2003: Message edited by: David Weitzman ]
Quoted from the words of Thomas Paul "The Saint" (Sheriff) Member # 970:
Jake, your name is in violation of the Javaranch naming standard. We allow you to use this name in "Meaningless Drivel" because that forum does not enforce the naming standard. All other forums strictly enforce the JavaRanch naming standard. If you use this name in any other forum again your account will be closed. -------------------- Associate Instructor - Hofstra University