This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Spring and the fly likes Reduce number of spring bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Reduce number of spring bean" Watch "Reduce number of spring bean" New topic
Author

Reduce number of spring bean

Patrick Kok
Ranch Hand

Joined: Nov 12, 2009
Posts: 42
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

Joined: Jul 05, 2005
Posts: 1936
100 objects are not too many. How much memory they use?


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Aditya Keyal
Ranch Hand

Joined: Dec 01, 2008
Posts: 71
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.


- Aditya Webservices Blog
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
And number of beans doesn't imply amount of memory they use.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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

Joined: Nov 12, 2009
Posts: 42
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

Joined: Sep 29, 2008
Posts: 12617

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

Joined: Feb 05, 2001
Posts: 17258
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
 
Don't get me started about those stupid light bulbs.
 
subject: Reduce number of spring bean