Forums:

Spring framework context and thread safety

Greenhorn

Posts: 2

posted 10 months ago

Number of slices to send:

Optional 'thank-you' note:

Send

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?

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

Stephan van Hulst

Saloon Keeper

Posts: 15608

366

posted 10 months ago

1
Number of slices to send:

Optional 'thank-you' note:

Send

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

Saloon Keeper

Posts: 27851

196

I like...

posted 10 months ago

1
Number of slices to send:

Optional 'thank-you' note:

Send

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.

The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.

You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.

Michael Straub

Greenhorn

Posts: 2

posted 10 months ago

1
Number of slices to send:

Optional 'thank-you' note:

Send

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

Saloon Keeper

Posts: 15608

366

posted 10 months ago

Number of slices to send:

Optional 'thank-you' note:

Send

You've got it!