EJB pooling vs Spring: how to manage work load in spring?

When an EJB application receives several requests (work load) it can manage this work load just POOLING the EJBs, so when each EJB object is being used by a thread, the next threads will have to wait queued until开发者_如何转开发 some EJB ends up the work (avoiding overloading and efficiency degradation of the system).

Spring is using stateless singletons (not pooling at all) that are used by an "out of control" number of threads.

Is there a way to do something to control the way the work load is going to be delivered? (equivalent to the EJB instance pooling).

Thank you!

In the case of the web app, the servlet container has a pool of threads that determine how many incoming HTTP requests it can handle simultaneously. In the case of the message driven POJO the JMS configuration defines a similar thread pool handing incoming JMS messages. Each of these threads would then access the Spring beans.

Googling around for RMI threading it looks like there is no way to configure thread pooling for RMI. Each RMI client is allocated a thread. In this case you could use Spring's Task Executor framework to do the pooling. Using <task:executor id="executor" pool-size="10"/> in your context config will set up a executor with 10 threads. Then annotate the methods of your Spring bean that will be handling the work with @Async.

Using the Spring task executor you could leave the Servlet and JMS pool configuration alone and configure the pool for your specific work in one place.

To achieve a behaviour similar to the EJB pooling, you could define your own custom scope. Have a look at SimpleThreadScope and the example referenced from this class' javadoc.

The difference between Spring and EJB is, that Spring allows multiple threads on an single instance of an bean, while in EJB you have only one tread per bean (at one point in time).

So you do not need any pooling in Spring for this topic. But on the other hand you need take care that you implement your beans in a threadsave way.

From the comments:

Yes I need it if I want to limit the number of threads that can use my beans simultaneously

One (maybe not the best) way to handle this is to implement the application in normal spring style (no limits). And than have a "front-controller" that accept the client request. But instead of invoking the service directly, it invokes the service asyncron (@Async). May you use some kind of async proxy instead of making the service itselfe asyncron.

class Controller{... 
  Object doStuff() {return asyncProxy.doStuffAsync().get();}
}
class AsyncProxy{... 
   @Async Future<Object> duStuffAscny{return service.doStuff();
}
class Service{... 
   Object doStuff{return new Object();}
}

Then you only need to enable springs Async Support, and there you can configure the Pool used for the Threads.

In this case I would use some kind of front controller, that starts an new Async