4.3.2 비격리 대책
개발자는 비격리로 인한 비정상을 방지하고 비즈니스에 미치는 영향을 최소화하는 방향으로 사가를 작성할 의무가 있습니다. 부담스럽게 들리겠지만, 이미 앞서 나왔던 *_PENDING 상태(예: APPROVAL_PENDING)도 이상 현상을 예방하는 전략 중 하나입니다. 주문 생성 사가처럼 주문을 업데이트하는 사가는 일단 주문을 *_PENDING 상태로 두고 시작합니다. 현재 주문을 사가로 업데이트하는 중이니 그에 맞게 행동하라고 다른 사가에게 알리는 것입니다.
이런 식으로 *_PENDING 상태를 두는 것은 <Semantic ACID properties in multidatabases using remote procedure calls and update prop agations(논문: 원격 프로시저 호출 및 업데이트 전파를 활용한 다중 DB에서의 시맨틱 ACID 속성)>(라스 프랭크(Lars Frank), 토르벤 U. 잘레(Torben U. Zahle) 저, 1998)에서 시맨틱 락 대책(semantic lock countermeasure)이라고 칭한 기법의 일례입니다.13 이 논문에는 분산 트랜잭션을 사용하지 않는 다중 DB 아키텍처에서 트랜잭션 비격리 문제를 처리하는 방법 등 사가 설계 시 도움이 될 만한 내용이 많습니다.
• 시맨틱 락(semantic lock): 애플리케이션 수준의 락
• 교환적 업데이트(commutative updates): 업데이트 작업은 어떤 순서로 실행해도 되게끔 설계합니다.
• 비관적 관점(pessimistic view): 사가 단계 순서를 재조정하여 비즈니스 리스크를 최소화합니다.
• 값 다시 읽기(reread value): 데이터를 덮어 쓸 때 그 전에 변경된 내용은 없는지 값을 다시 읽고 확인하여 더티 쓰기(dirty writes)를 방지합니다.
• 버전 파일(version file): 순서를 재조정할 수 있게 업데이트를 기록합니다.
• 값에 의한(by value): 요청별 비즈니스 위험성을 기준으로 동시성 메커니즘을 동적 선택합니다.
비격리 대책을 자세히 살펴보기 전에, 먼저 사가의 구조를 나타내는 용어를 몇 가지 소개합니다.