Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple usage of repository setup means (XML or annotation) creates multiple bean definitions for RepositoryInterfaceAwareBeanPostProcessor [DATACMNS-609] #1072

Closed
spring-projects-issues opened this issue Nov 30, 2014 · 5 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Nov 30, 2014

Victor Bronstein opened DATACMNS-609 and commented

Apparently every time the tag jpa:repositories is used in XML files, a new instance of RepositoryInterfaceAwareBeanPostProcessor is created and registered with the bean factory. This is mainly a performance problem because predictBeanType(…)-method is then called N times for every relevant bean. This can easily be reproduced with the version 51d1c5d of git@github.com:spring-projects/spring-data-jpa-examples.git by adding an extra stanza like <jpa:repositories base-package="org.springframework.dummy" /> to simple-repository-context.xml and running XmlConfigCachingRepositoryTests.


Affects: 1.9.1 (Evans SR1)

Issue Links:

  • DATASOLR-218 Improved bean definition registration for repository configuration

  • DATACMNS-611 Avoid triple cache lookup in RepositoryInterfaceAwareBeanPostProcessor.predictBeanType(…)

Backported to: 1.9.2 (Evans SR2)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 30, 2014

Oliver Drotbohm commented

Good catch, Victor! This really should be fixed. What I am wondering though is: is this really causing a performance problem? Even if these beans get called multiple times, the method call should immediately return as the type assignment check fails right away. Am I overseeing something here? Just wondering as we otherwise might be able to improve the performance for a single bean registration, too

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 30, 2014

Victor Bronstein commented

Thank you for picking it up so quickly, Oliver! It's definitely not a major performance problem. You're right, for most beans it returns right away. However, when it does some work, it does it far too many times. In our case we ended up with no less than 73 instances of this post-processor in the bean factory - yes, I'm sorry :) - so the total overhead reaches a couple of seconds.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 1, 2014

Oliver Drotbohm commented

Does that mean you have <jpa:repositories … /> declared 73 times? o.O

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 1, 2014

Victor Bronstein commented

Different XMLs, different modules, but yes. A large Spring context...

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 2, 2014

Victor Bronstein commented

Oliver, you might not believe it but after I applied the fix you made in 6677612 the startup time of our application has decreased by about 45 (forty five) seconds!
The thing is that there is a substantial number of usages of @Autowired in our Spring context. The method predictBeanType of bean post processors is used very heavily by the autowiring logic. Having 72 extra instances of a certain bean post processor didn't exactly speed things up ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants