thread safe, stateless design using Spring

NimChimpsky picture NimChimpsky · Jun 25, 2012 · Viewed 9.3k times · Source

I have assumed that if instance variables are managed by spring IOC, and are singletons that the desgin can be called stateless and threadsafe.This type of desgin could consequently be scaled to clustered servers. Am I correct in my assumptions,outlined below ?

@Repository("myDao")
public class MyDao implements Dao {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Value("${sqlFoo}")
    private String foo;

    @Override
    public Integer getMyInt(String str) {
      return jdbcTemplate.queryForInt(foo, str);
    }

which is then injected into :

@Service("myService")
public class MyServiceImpl {

    @Resource(name = "myDao")
    Dao dao;

    @Override
    @Transactional(readOnly = true)
    public int getScore(String str) {
      return dao.getMyInt(str);
    }
}

Answer

Tomasz Nurkiewicz picture Tomasz Nurkiewicz · Jun 25, 2012

Spring beans aren't stateless because they have state (fields). Technically they aren't even immutable because you can change injected fields at any time.

However you can easily make Spring beans immutable by using final fields and constructor injection. Also this kind of state is not problematic from scalability point of view. If your beans contain mutable values that change over time, this is a major issue when clustering. But in Spring services typically contain only dependencies injected at bootstrap time. So they are effectively stateless and immutable.

It doesn't matter on how many servers you run the same Spring application - the beans and dependencies themselves are safe. But if you Spring beans contain counters, caches, mutable maps, etc. - you need to think about them.