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

Thread-safety and visibility issues not documented [SPR-4307] #8986

Closed
spring-projects-issues opened this issue Jan 7, 2008 · 4 comments
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: documentation A documentation task
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Stefan Fleiter opened SPR-4307 and commented

Neither spring's reference documentation nor the Javadoc mention the context thread-safety and visibility guarantees.

What can happen when multiple threads query for a bean during its' creation (singleton and prototype)?
Is it guaranteed that all threads see changes made by constructors and setters?
Does FactoryBean#getObject() has to be implemented thread-safe?

After a short analysis of AbstractBeanFactory all these aspects seem to be handled by the spring context.

Please document this.
The most important place is the reference documentation:
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html
The Javadoc for all ApplicationContext- and BeanFactory-Classes should also state this.

Thanks a lot in advance.


Affects: 2.5 final

4 votes, 7 watchers

@spring-projects-issues
Copy link
Collaborator Author

Stefan Fleiter commented

When you search the web you find many questions regarding this issue:

For exmaple:
http://weblogs.java.net/blog/tomwhite/archive/2006/09/are_your_beans_1.html
http://forum.springframework.org/showthread.php?t=11791

@spring-projects-issues
Copy link
Collaborator Author

Stefan Fleiter commented

FactoryBean#getObject() is a quite complex.

Are all getObject() calls triggered by the context guaranteed to

  • be done in a serialized manner?
  • have "at most once"-semantic?
  • see all changes done by other calls to getObject() of the same class (multiple bean instances)?
  • see all changes done by other calls to getObject() of other classes?

The code does seem to speak that language, but it is not guaranteed since there is no contract
for this in reference doc or Javadoc.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I've partly addressed this for 2.5.2 already. To be completed for 2.5.3.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Rafael Winterhalter commented

Is this still on someone's plate? I had a short look and I hopefully backwards-engineered this matter in this answer on SO: http://stackoverflow.com/questions/23906808/should-i-mark-object-attributes-as-volatile-if-i-init-them-in-postconstruct-in/23992532#23992532

I would still prefer to have an official source for this. Thanks!

@spring-projects-issues spring-projects-issues added in: core Issues in core modules (aop, beans, core, context, expression) type: task A general task labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.x Backlog milestone Jan 11, 2019
@jhoeller jhoeller added type: documentation A documentation task and removed type: task A general task labels Jul 14, 2023
@jhoeller jhoeller modified the milestones: 6.x Backlog, General Backlog Sep 15, 2023
@jhoeller jhoeller self-assigned this Dec 27, 2023
@jhoeller jhoeller modified the milestones: General Backlog, 6.1.3 Dec 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: documentation A documentation task
Projects
None yet
Development

No branches or pull requests

2 participants