Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Reduce number of spring bean

 
Patrick Kok
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Can anyone give me suggestions of how to reduce number of spring bean?
The current spring beans just too many over 100 with additional session bean.
It occupies memory space too much.

We use struts2 and hibernate.
please help.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
100 objects are not too many. How much memory they use?
 
Aditya Keyal
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And number of beans doesn't imply amount of memory they use.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And it depends on what the beans are, how and when they're used, etc. As Kengkaj said, a hundred beans isn't very many--a large system might have an order of magnitude more.
 
Patrick Kok
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks
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.

thanks

 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Hope that helps.

Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic