<b>Spring MVC thread safe distilled</b><br><br>I come across this question wh...

Terrence Miao - 2012-10-26 23:15:28+1100 - Updated: 2012-10-27 15:29:56+1100

Spring MVC thread safe distilled

I come across this question when a controller in Spring MVC which scope is Singleton, is it thread safe?

The answer is NO.

According to java concurrency thread safety is that the shared data, like instance variables and can be modified, then the Singleton Spring MVC controller has the instance variables, or injected autowired Spring bean isn't 100% thread safe. But when member variables, inside the method body, then they are thread safe and no need for synchronised.

Now come along some goodies of the best practice of playing thread safety in Spring by following these simple rules:

1. Don’t use states on Controllers, Service Layer Objects and DAOs
2. If you can’t avoid, first rethink your design, unless you have to use synchronized
3. If you want to use prototype scoped beans, be aware of instance explosion

Dean Budd - 2012-10-27 14:29:42+1100

Agreed. I'd be highly suspicious if you had state in your controllers and would agree something is wrong with the design i.e Misplaced Responsibility?

Kieran Simpson - 2012-10-27 16:51:43+1100

This is one of the many reasons I'm encouraging my team to 'code for immutability'. By declaring variables to be final first you're protecting against the reference value being changed, and thus improving the thread safety of your beans.

Oleg Kiorsak - 2012-10-27 18:56:25+1100

one very widespread idiotic "practice" is "diligently" adding getters and setters (!!) where there is absolutely no need for them (especailly for the setter)...
also externally exposing lists, maps, etc (again via getters ;)...
all of this makes for inherently thread UN-safe code...

Terrence Miao - 2012-10-27 20:22:22+1100

+Oleg Kiorsak One thing I don't like Java POJO in Action is the spreading of poison of Getters and Setters. In most case, they have default behaviour and shouldn't specify explicitly. So that's why I like MetaClass interface within Groovy could defines the behaviour POJO like for Groovy or Java class.

Less is more.

Less code is always clean, better and reliable code. Less code reflects clean design and simple approach to solve the complicated problem.

Kieran Simpson - 2012-10-27 20:24:55+1100

If you have so many getters and setters +Terrence Miao I would ask whether you have a data structure (or Value Type) and thus why not make all the fields public and get rid of the getters and setters?

Oleg Kiorsak - 2012-10-27 20:39:08+1100

on top of having at least some level of awareness regarding concurrent and thread safety, I think that tools like FindBugz are you friends too...

Terrence Miao - 2012-10-27 22:06:57+1100

+Kieran Simpson I think the common practice is that POJO must be accessible using get, set, following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks.

We have data structure but that wouldn't prevent integration architect defined an object in integration layer with hundreds properties. We have the transformer classes which one class could over 1000 lines code threshold just do data mapping. Ironically, IDE automatically generates getters and setters developers have to manually write unit test on getters and setters.

Is this a design issue? I think so ...

James Gemmell - 2012-10-28 15:34:03+1100

Try http://code.google.com/p/bean-matchers/ (as suggested by +Kieran Simpson) or http://code.google.com/p/openpojo/ for automating your POJO tests.

The subject of when to use getters and setters came up in one of our Friday Java questions. In a IoC assembled world, Service Layer Objects, Controllers and DAOs only require setters - IMHO having getters only encourages gratuitous violations of the Law of Demeter. DTOs, value objects, entities and the like obviously need getters. Unless required by the framework, setters can be dispensed with in favour of constructor args.

Kieran Simpson - 2012-10-28 21:06:11+1100 - Updated: 2012-10-28 21:06:35+1100

IMHO +James Gemmell if you're having your value objects being immutable I think it's better that all the fields are public final with associated Builders if construction requires multiple steps/sources. Methods imply behaviour where what you really have is dumb data structures (with a few helper methods thrown in if needed ie: equals or toString) It also prevents source file bloat as your average getter (especially if it's autogenerated by ones IDE) is ~3 LOC. Since going that way myself I've been reading value objects, DTOs, etc in a new way and have successfully resisted the urge to place behaviour into them that really belongs somewhere else. If it walks too much like ~~a duck~~ an entity, people want to make it one.

Just my 1c :)

Terrence Miao - 2012-10-28 23:40:55+1100

+James Gemmell Will give a bean matcher try later. Cheers.