Thats too vague a ques. The number of beans would be depending on the size of your application and more importantly on the design. So if you are looking at a solution you need to through a lot more light coz i don't think there is any sure shot way to reduce the no of beans.
We don't have much experience in Spring 2.5 (and struts2,hibernate integration), but we do coding for many years.
The main idea of reducing number of bean is to allow great amount of user volume.
These beans are prototype and sessions, we think there will be much more, may be over 300 for each user session.
Our management people would like to gather our suggestion to what scale of hardware to fit such loading with their expected visiting volume. This is tough since we don't have such figures in the development state.
If I am correct (Correct me if I am wrong),
I checked Spring spawns all singleton beans when sever startup for all associated xml, and keep them, and wait for use throughout the service. However, we needs prototype bean, and spring will simply create it to me for each request. These beans will be destroyed after the spring life cycle. This wouldn't be a problem.
Now, we found that we must use session bean to differentiate our model layers, and there will be a lot of these (design problem? may be). These beans will surely occupy much memory.
I need some suggestions from you guys. Please correct me if I am wrong in Spring working mechanism.
We start our service with limited resources, we hope this setup can maintain stable amount of constant user volume.
Without knowing what you're actually doing, it's going to be extremely difficult to provide any useful input. Saying "300 beans per user session" doesn't really give enough information to go on. To me that seems a very high number, but I have no idea what your application is, what those 300 beans contain, what their lifecycle is, and so on. I've worked on some pretty massive systems, and I've never had to create 300 Spring beans per user session that needed to all be "alive" at the same time--that strikes me as very odd. But again--I have no way of knowing.
In the web apps that we have done, we don't use Prototype. There are only rare occasions where that is needed. So what that says to me is that you put domain/data holding beans in your application context. The type of beans that usually go into the application context are beans that don't hold state, are thread safe, meaning they are services and DAOs mostly, besides all the infrastructure beans like DataSource, TransactionManager etc.
To me, and this is my opinion, if you find that your architecture is designed such that you need all your beans to be prototype that that means there is something wrong with the architecture. Now don't go to your architects and say I told you that they don't know what they are doing, because I don't know them, I don't know your architecture, and it could be good. But all beans being prototype. 300 beans per users are big huge red flags to me.