part 8. 애그리거트 트랜잭션 관리

애그리거트 트랜잭션 관리

애그리거트 트랜잭션

발생원인

• 애그리거트라는 개념은 개념적으로 동일한 애그리거트를 이용할때 발생할 수 있다.
• 2개 이상의 호출에서 동일한 개념적인 애그리거트에서 서로 다른 기능을 수행하고 저장하는 경우에 어떤 호출이 먼저 저장되는지에 따라 최종적인 쓰기가 승리하는 방향으로 가게된다. 배송과 배송지 수정을 예로 들어보면 배송이 출발한 후 배송지 수정이 가능하게 되는 문제가 있다.
• DB 격리수준과는 무관한가?
  • read uncommited : 그냥 무관
  • read commited : 커밋전 결과를 읽는것이 아니라서 dirty read 와는 무관
  • repeatable Read : tx 버전과는 무관함
  • serializable : row lock을 사용하면 해결이 가능함.
    • 어떻게 serializable 을 사용하게 된는지 앞으로 알아 봅시다.
  • tx2: Read → Write
• 최종쓰기 승리를 제공하는 NoSQL에서는 어떻게 사용해야하는가??

애그리거트 잠금기법

pessimistic lock

• 데이터를 가져오는 동안 어떤 데이터도 해당 애그리거트에 접근할 수 없음

@Lock(LockModeType.PESSIMISTIC_WRITE)
@QueryHints({
	@QueryHint(name = "javax.persistence.lock.timaout", value = "2000")
})

를 이용해서 잠금을 설정함.

• 당연하게도 교착상태에 빠질 수 있음 이런 경우 Qeury hint 를 이용하자
• DBMS 에서 JPA가 어떤 룰로 대기시간을 설정하는지 알아두자.
• 완벽할까?
  • Optimistic lock의 예시를 보면 조금 문제강 있음.
  • 만약 사용자에게 아래와 같은 기능을 제공하면 어떻게 되는가? (transaction이 나뉘어짐)
    • 사용자가 뷰를 확인한다.
    • 사용자가 데이터 쓰기를 요청한다.

Optimistic lock

• pessimistic lock 이 대응하지 못하는 예시
  • 운영자는 배송을 위해 주문 정보를 조회한다. 시스템은 정보를 제고앟ㄴ다.
  • 고객이 배송지 변경을 위해 변경 폼을 요청한다. 시스템은 변경 폼을 제공한다.
  • 고객이 새로운 배송지를 입력하고 폼을 전송하여 배송지를 변경한다.
  • 운영자가 1번에서 조회한 주문 정보를 기준으로 배송지를 정하고 배송 상태 변경을 요청한다.
• 현재 버전을 db에 저장함으로 해당 필드를 업데이트해가면서 조회당시 버전과 데이터가 같을때만 저장하도록 진행한다.
  • 모든 read → update 과정에서 version을 비교하고 저장할 필요가 있을까?
    • 전체가 같은지 확인하거나 비즈니스 로직만 확인하면 되는거 아닌가?
    • 대부분의 경우에는 필요하지 않을거 같음
• OptimisticLockingFailureException이 @Transaction 사용시 발생한다. 반드시 알아두자.
• classmate service 에서는 어떤 필드가 OptimisticLock이 처리되어있는가?
• view단에서도 Optimistic lock field를 전달받고 돌려주어야함.
• 만약 필드가 완전히 다른 필드를 이용하게 된다면?
• JPA에서 강제버전증가가 필요한 이유는 무엇인가??
• @version 으로 되어있는 부분이 다른 table에 존재해서 해당 테이블을 업데이트 하는것이 아니기때문에 해당 기능이 필요함.

오프라인 잠금

• lockManager를 구현하여 데이터를 저장하고 관리한다.