기존 엔터프라이즈 애플리케이션의 '동기화' 키워드가 의심스럽습니까?

Question

저는 전형적인 기업용 애플리케이션에 대해 이야기하고 있습니다.일반적으로 일종의 애플리케이션 서버 또는 컨테이너에서 호스팅됩니다.화려한 것은 없고 엔터티, 서비스, 프레젠테이션/UI 및 관계형 저장소만 있습니다.

내가 볼 때마다 synchronized 그러한 애플리케이션에서 키워드(메소드 또는 블록)는 매우 의심스럽습니다.내 생각에 이것은 기본 아키텍처 개념을 이해하지 못했다는 신호이거나(예를 들어 도메인 모델이 여러 클라이언트 간에 공유되지 않음) 더 나쁘게는 아키텍처가 실제로 매우 잘못되었다는 신호입니다.

여기에 내 사고 방식을 공유합니까?아니면 제가 완전히 궤도를 벗어난 걸까요?기존 엔터프라이즈 애플리케이션에서 실제로 동기화가 필요한 사용 사례가 있습니까?

Answer 1

비즈니스 로직 코드에 대해 동의하지만 엔터프라이즈 응용 프로그램에는 기술 코드도 있으며 때로는 공유 '기술'상태에 대한 동기화가 필요합니다. 동기화 된 키워드가 사용될 수 있습니다. (또한 원자 변수를 전달하거나 기술 상태를 공유하기 위해 DB 시퀀스와 같은 응용 프로그램 외부에서 무언가를 사용할 수도 있습니다 ...)

순서대로 구멍이없는 순차 청구서 번호를 작성하려면 일부 상태를 공유하는 방법과 동기화 방법이 필요합니다 ...

Answer 2

나는 당신에게 동의합니다.

나는 스레드로부터 안전한 구성요소를 설계할 때 동기화가 중요하다고 생각하지만 "비즈니스 로직" 코드에서는 일반적으로 필요하지 않습니다.

공유 상태를 도입하면 성능을 높일 수 있지만 향후 애플리케이션의 확장성은 감소하게 됩니다.

동시 설계가 필요한 경우 애플리케이션 서버 등을 사용하여 애플리케이션 개발자에게 투명하게 처리할 수 있습니다.