Is the "synchronized" keyword in a classic enterprise application suspicious?

I am talking about classic enterprise applications. It is usually located in some server application or container. Nothing unusual, just entities, services, presentation / user interface and relational storage.

Whenever I see the synchronized (or methods or blocks) in such an application, I become very suspicious. In my opinion, this is either a sign of a lack of understanding of basic architectural concepts (for example, that the domain model is not shared among several clients), or an even worse sign that the architecture is actually very unsuccessful.

Do you share my thinking here? Or am I completely unaware? Do you have cases when synchronization is really necessary in a classic enterprise application?

+4
source share
2 answers

I agree with you regarding the business logic code, but in a corporate application you also have a technical code, and sometimes you need synchronization for a general "technical" state. The synchronized keyword can be used for this. (You can also pass in an atomic variable or use something outside your application as a database sequence to share the technical state ...)

If you want to create an account serial number - without holes in the sequence - you need a way to share a certain state and a way to synchronize ...

+2
source

I agree with you.

I think that synchronization is important when developing thread-safe components, but usually this is not required in business logic code.

By presenting the overall state, you can increase productivity, but reduce the scalability of your application for the future.

If a parallel design is required, it can be transparently processed by the application developer, for example, using the application server.

0
source

All Articles