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

Open
spring-issuemaster opened this Issue Jan 7, 2008 · 4 comments

Comments

Projects
None yet
1 participant
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Jan 7, 2008

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 7, 2008

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 7, 2008

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Feb 26, 2008

Juergen Hoeller commented

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

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jun 2, 2014

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment