>Why NOT Stateless Session Bean be a multi-threaded..where >SINGLE instance of bean is running in the server. Instead of >polling the app server can made it multi-threaded one so that >we can conserve resources like memory.
Memory is really not an issue because the memory footprint of the SLSB object itself is very small (since the object has no state). The app server services such as transactions, security, load balancing, etc. account for much more of the memory usage. The decision to make SLSBs single threaded is a simplicity issue more than anything else. It's easier for a developer to error when coding multithreaded objects than when coding single threaded objects. Multi-threaded complications get compounded inside the app server by the existence of clustering, transactions, and security. Therefore, the app server assumes total control over how threading issues are handled, and the component developer is given a simple single threaded view into the system. Bottom line: Simplicity is far more precious commodity than memory. The memory requirements of a single threaded system are negligible compared to the vast simplicity gains. >The multi-threaded stuff is implemented in Servlet Model(I mean if >Servlet does not implement SingleThreadModel interface). When servlets were designed, usecases for stateful servlets where envisioned (a counter for example). So having a single instance was necessary. However, the use of a single shared stateful component creates an immediate clustering problem, since servlet state isn't easily shared between servers. So when they went to add clustering support to the servlet spec, they had to relax the single instance guarantee (in a cluster there will be multiple instances). In the case of EJB, since it was designed from the ground up to (a) be clusterable and (b) encourage stateless design, the designers saw little need for a multi-threaded session bean. Again, simplicity, not minor memory gains, is the driving issue here. Doug Bateman =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
