예를들어서 단순히 ConcyrrentHashMap에다가 Map<재고ID, 버전을 담는 AtomicInteger>가 있을때, 버전이 바뀌지 않은 경우에만 어떤 로직을 실행하도록 묶어준다 한들,
그 로직을 내부에서 실행하면서 마주칠 변수들이 thread-safe하지않으면 결국 동시성 문제는 해결이 안되는거 아님?
예를들어서 단순히 ConcyrrentHashMap에다가 Map<재고ID, 버전을 담는 AtomicInteger>가 있을때, 버전이 바뀌지 않은 경우에만 어떤 로직을 실행하도록 묶어준다 한들,
그 로직을 내부에서 실행하면서 마주칠 변수들이 thread-safe하지않으면 결국 동시성 문제는 해결이 안되는거 아님?
당연한 소리임 read랑 update랑 원자적 단위에서 이뤄져야 하며, compareAndSet을 사용해서 read랑 update를 원자적인 단위로 수행해야함
사실상 단일 필드 딸깍 + Atomic한 Primitive를 이용하는 선에서 해결이 가능한 경우에는 낙관적 락을 고려할 필요 조차 없어질거 같고, 글에서 상술한대로 Map에서는 버전관리만 해주고 실제 로직 자체는 객체 내 여러 필드와 엮여서 이뤄진다고 할 때는 너가 말한대로 read랑 update가 원자적 단위로 이뤄져야만 의미가 있는데, 이러한 경우는 AtomicReference나 AtomicStampedReference라는 구현체가 있네 ㄷㄷ
사실 낙관적 락을 어떻게 정의하느냐에 따라 AtomicInteger에 대해 CompareAndSet을 적용한거에 대해서 Integer에 대한 낙관적락이라고 할 수도 있고, AtomicReference를 쓴다면 객체의 참조에 대한 낙관적락 => 객체 수준에서의 낙관적락이라고 생각할 수도 있을거 같은데 잘 모르겠네
그렇네 하나 배워간다 ㄳ
낙관적락 자체는 동시성 문제 발생안함 버전일치 판단을 애플리케이션 지역변수에서 하기때문에 버전을 공유하는게 아니라 인스턴스가 다 다르게 잡힘 - dc App
이 친구는 어플리케이션 레벨에서 낙관적 락 메커니즘을 구현할 때를 질문한 것 같은데
응? 그러네 내가 생각한 로직이랑 좀 다른데 - dc App