Question

I wanted to understand better how and when it makes sense to use the prototype scope in Spring. Seems that it is similar how the stateless session beans have been handled in the EJB world (although, the EJB container would release an instance from a pool of stateless session beans that would be created rather than creating a new instance on demand).

I have a few basic questions about that:

1) From an architecture standpoint, when does it make sense to use prototype-scoped beans in a typical J2EE web application (Spring MVC/Hibernate or JDBC template DB access)?

2) Is there a concept of creating a pool of such prototype instances similar to the pooling that the EJB server would do with the stateless session beans?

3) Should the service facade (that is similar to the Session Facade in EJB) be created with a prototype scope and would that help in dealing with the concurrent requests coming from a web tier? And how do I control the number of instances that are created (limit to certain manageable number and, preferably, pool them)?

Answer 1

you would want singletons for services, assuming your services are stateless. That way you only have one instance of each service, and since they are stateless they are threadsafe.

you would want prototypes for things like request actions (e.g. in struts), so a new object gets created to handle each request. Those prototypes can be wired up to singleton services.

from the documentation:

The non-singleton, prototype scope of bean deployment results in the
creation of a new bean instance every time a request for that specific
bean is made. That is, the bean is injected into another bean or you
request it through a getBean() method call on the container. As a
rule, use the prototype scope for all stateful beans and the singleton
scope for stateless beans.