Spring framework context and thread safety

[Michael Straub]

TL;DR: If singleton beans in Spring's context are not threadsafe, how do we manage multiple requests/threads accessing the service bean and not creating inconsistency?

Hi,
I have done some java SE coding and currently reading Spring Start Here by Laurentiu Spilca.
As we are introduced to prototype beans in section 5.2, thread safety is brought up and how mutable objects must be handled by prototype beans(instead of singleton beans) to avoid race condition. But my confusion is that the singleton bean(CommentService) that is creating the prototype beans(CommentProcessor) is not thread safe either. So to make it thread safe we will have to synchronize sendComment()? Would not this effect performance?

@Component
public class CommentService {
@Autowired
private ApplicationContext context;
public void sendComment(Comment c) {
CommentProcessor p = context.getBean(CommentProcessor.class);
p.setComment(c);
p.processComment(c);
p.validateComment(c);
c = p.getComment();
// do something further
}
}

@Component
@Scope(BeanDefinition.SCOPE_PROTOTYPE)
public class CommentProcessor {
@Autowired
private CommentRepository commentRepository;
// Omitted code
}

Thanks and if I am not clear please let me know
_M

[Stephan van Hulst]

Welcome to CodeRanch!

Michael Straub wrote:TL;DR: If singleton beans in Spring's context are not threadsafe, how do we manage multiple requests/threads accessing the service bean and not creating inconsistency?

Singleton beans MUST be thread-safe, in every case.

But my confusion is that the singleton bean(CommentService) that is creating the prototype beans(CommentProcessor) is not thread safe either.

Why? What makes you think that CommentService is not thread-safe?

So to make it thread safe we will have to synchronize sendComment()? Would not this effect performance?

You must NEVER synchronize on singleton beans. To make them thread-safe, they must be stateless. You do this by making them immutable.

The CommentService class is immutable, and therefore thread-safe.

[Tim Holloway]

I would be a little cautious stating that,

By default the Spring BeanFactory will construct and decant single instances of beans, so in the literal sense yes they are singletons. But they are NOT expected or required to be strict GoF-style Singleton objects.

Spring beans are often stateful, in fact. Where that may result in threading concerns, it is up to the bean itself to manage any sort of synchronization mechanisms required. Spring doesn't get involved. Spring's participation in threading and other asynchronous concerns is limited to optional Spring add-on modules, not the Spring core.

It's perfectly permissible for a bean managed by a Spring BeanFactory to define and enforce itself as a hard-code GoF singleton object, But it is definitely not required to, and usually not worth the extra work.

[Michael Straub]

Thank you for your explanations!

I realized that if singleton bean CommentService(which is stateless) asks the container for a prototype bean CommentProcessor, each thread will have its own copy of CommentProcessor, thus making it thread safe. No shared data among threads anymore! Neat trick

[Stephan van Hulst]

You've got it!