• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Such Honesty

 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok,
I'll be honest; I just want to win a copy of the book.
If Spring can live up to its reputation and truly offer us a replacement for the monolithic frameworks like EJB, then it will be around for 7 years.

I believe the best way to increase the momentum of Spring is to release examples, well contructed of course, covering all of the major aspects that a typical enterprise application might have to cover. Persistence (object and relational), async messaging, ui, distributed transactions, web services, clustering, failover, debugging, ease of maintenence, you get the picture.
Show us how Spring helps in all of these and it will take the lead.

A question; Has anyone done a study to see if Spring noticeably increases the number of small objects created in the JVM, which might cause excessive GC activity? No accusations, just a question, thanks.
-jeff walker
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Walker:

A question; Has anyone done a study to see if Spring noticeably increases the number of small objects created in the JVM, which might cause excessive GC activity? No accusations, just a question, thanks.



I personally haven't done any formal study on this, but Ryan and I can attest to a project we worked on where upon retrofitting the application to use Spring, we saw a 1/3 reduction in the number of classes (this is all from my hazy memory of the project...Ryan may remember it better).
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If Spring can live up to its reputation and truly offer us a replacement for the monolithic frameworks like EJB, then it will be around for 7 years.



7 years? How did you calculate this?
 
Jeff Walker
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:


7 years? How did you calculate this?



I picked a number in the heat of the moment after a tough day with EJB production problems. Ha!-jeff
 
Jeff Walker
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Craig Walls:


I personally haven't done any formal study on this, but Ryan and I can attest to a project we worked on where upon retrofitting the application to use Spring, we saw a 1/3 reduction in the number of classes (this is all from my hazy memory of the project...Ryan may remember it better).



Craig,
thanks for replying.
Was that a reduction in the number of loaded classes or in the actual number of object instantiations? Cheers!
-jeff walker
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Walker:


Craig,
thanks for replying.
Was that a reduction in the number of loaded classes or in the actual number of object instantiations? Cheers!
-jeff walker



uhhm good one , so you want to know how the Spring Bean Factory behaves.
I'm not very sure about my reply. but ofcourse Craig will confirm.
Spring either supports singleton / prototype beans.
In your code instead of doing a new Class(), you do BeanFactory.getBean().
If the bean is configured as a 'prototype' , you will always get a new instance. So its as good as doing a new explicitly. If the dependent bean is a singleton then it will pick the singleton instance else (if its a proptotype) it has to create a new instance of the dependent bean as well.
Spring Bean factory does'nt look like an object pool to me ( i guess thats the only way spring can control the number of instances in the memory).

Uhhm wait,

here the author mentions there is a way to configure a pool.
 
author
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Before I reply, let me say that this is speculation on my part - I have never done any profiling with Spring (never had a reason to). That said...

I seriously doubt using Spring will have any impact on GC performance problems. First, in a typical application, most objects used by Spring will either be container objects internal to Spring or your application's "infrastructure" objects (DAOs, service objects, aspects, MVC support objects, etc). These will all most likely be singleton objects that will live for the lifetime of your application. In other words, GC friendly objects.

For those objects that are created ofter, these will either be your applications domain objects or Spring prototype beans. Either way, these will usually be cheap objects to create. Also, you *need* to create these objects as these are going to be stateful, usually short lived objects. This behavior will be the same for non-Spring applications as well.

Finally, any Spring object creation during the runtime of your application will probably be relatively small to the number of objects created by other parts of your application, such as your persistence layer or your web container.

So, I think it is a fair assumption that Spring will not add any significant GC overhead.
 
author
Posts: 184
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is the EJBs that are heavy weight.
(Nothing against EJBs. I actually like MDBs and Session EJBs where applicable. I actually use them big time in a system that really really needs remoting.)

On the other hand here is some fact: For a given O/R tool (it was actually TopLink) Getting rid of Entity EJBs increased performance (CPU util, memory usage) by 8-10% under normal load.

Spring objects are lightweight. They dont affect scalability at all. Actually we did some bench marking with Session EJBs v/s Spring

Stateless Session EJB based system was "just a bit" memory intensive - not too significant. I dont recall the CPU utlization.

However at the end of the day its all about ease of development and testing out of container. My experience is that if it is time consuming to test, then nobody tests at all.

If I were to redesign all the systems I worked on, I would use Spring without second thoughts
[ April 15, 2005: Message edited by: Srikanth Shenoy ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic