views:

125

answers:

2

I am talking about classic enterprise applications. Typically hosted in some kind of application-server or container. Nothing fancy, just entities, services, Presentation/UI and relational storage.

Whenever I see the synchronized keyword (either on methods or for blocks) in such an application I get very suspicious. In my opinion this is either a sign for not understanding basic architectural concepts (for instance that a domain model is not shared between several clients) or even worse a sign that the architecture is actually very botched.

Do you share my mindset here? Or am I completely off track? Do you have use cases where synchronization is actually necessary in a classic enterprise application?

+2  A: 

I agree with you for business logic code, but in an enterprise application you also have technical code and sometimes you need some synchronization for shared 'technical' state. The synchronized keyword may be used for this. (You also may relay on atomic variable, or use something outside your application like a DB sequence to share technical state...)

If you want to create sequential bill number - with no holes in the sequence - you need a way to share some state, and a way to synchronize...

pgras
I agree. I was talking about 'business logic'. My point is, that in modern platforms I usually don't see any reason to write 'technical code'. For me such 'technical code' is usually another sign, that people did not understand the technology and are reinventing the wheel.
jbandi
A: 

I agree with you.

I think synchronization is important when designing thread-safe components but it is not normally necessary in "business logic" code.

By introducing shared state you can increase performance but you are decreasing the scalability of your application for the future.

If a concurrent design is necessary it can be handled transparently to the application developer, for instance using an application server.

parkr