[#SPR-4498] @Configurable abstract parent bean with inner bean causes progressive slowdown

Spring Framework

@Configurable abstract parent bean with inner bean causes progressive slowdown

Created: 25/Feb/08 10:13 AM Updated: 25/Feb/08 02:12 PM

Component/s:

SpringCORE

Affects Version/s:

2.5 final

Fix Version/s:

2.5.2

Time Tracking:

Not Specified

File Attachments:

applicationContext-test.xml (2 kB)
2.

ConfigurableSpeedTest.java (1 kB)
3.

MyChildBean.java (0.1 kB)
4.

MyConfigurableBean.java (0.5 kB)
5.

MyInjectedBean.java (0.0 kB)

Platform:

Tomcat - 5.0

Description

« Hide

An abstract parent bean that contains an inner bean causes a progressive slowdown as more beans of that type are instantiated. See the enclosed unit test.
The slowdown was traced to BeanDefinitionValueResolver.adaptInnerBeanName() looping, trying to create a new unique bean name. It seems that the old inner bean names never get cleaned out of DefaultSingletonBean.dependentBeanMap.

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permlink | « Hide ]

Juergen Hoeller added a comment - 25/Feb/08 01:25 PM

The problem here is that your template bean definition for @Configurable is not marked as scope="prototype". This is why Spring thinks it needs to track all instances of that bean.

So as a workaround for this problem - and an actual recommended way of defining bean definitions for @Configurable - mark such template bean definitions as scope="prototype"!

That said, I'll still try to revise things in order to make such bean definitions work even when not explicitly marked as prototype.

Juergen

[ Permlink | « Hide ]

Mark Erinoff added a comment - 25/Feb/08 01:52 PM

I understand and agree. However please do make it work as-is to save others the pain we experienced. This problem showed up in pre-existing code (objects instantiated by Hibernate) only after running for a while. It was a bear to track down - our inclination was to think it was a Hibernate problem:-).
BTW, I noticed that @Configurable beans that are "abstract=true" can be directly new()ed. Is this a bug?

Thanks,
Mark

[ Permlink | « Hide ]

Juergen Hoeller added a comment - 25/Feb/08 02:12 PM

I've fixed AbstractAutowireCapableBeanFactory's "configureBean" (as used for @Configurable) to avoid bean name creation for inner beans, no matter whether the target bean definition is marked as prototype or not.

The "abstract" marker doesn't directly affect @Configurable classes. The bean definition serves as a template only, with instantiation characteristics being up to whoever actually instantiates the class.

@Configurable bean definitions are often marked as "abstract" to indicate that they are not supposed to be instantiated through the BeanFactory itself (which is what the "abstract" marker on a bean definition actually implies).

Juergen