Today I Learned

오늘은 과제 중 의문이 들었던 @Transactional의 의존성 문제 대해 좀 더 고민해보았다.

Transaction

: 트랜잭션, 데이터베이스에서 데이터에 대한 하나의 논리적 실행단계.

• ACID : 원자성, 일관성, 고립성, 지속성. 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어

• 트랜잭션의 특징 : 더이상 쪼갤 수 없는 최소단위의 작업. 하나의 최소단위의 작업에 여러가지 데이터 변경을 넣으면 모두 저장 or 아무것도 저장되지않음 (All or Nothing)
  트랜잭션 상에서 모두 성공을 해야 전부 반영. 중간에 하나라도 실패시 이전으로 롤백

@Transactional

@Transactional 을 달면, AOP를 활용해서
트랜잭션이 정상적으로 모두 실행되었을 때만 DB에 commit을 시키고,
하나라도 예외가 발생하면 트랜잭션을 롤백시킨다.

dependancy

SpringBoot의 데이터 엑세스를 위한 depandancy가 추가되어 있어야 한다.
일반적으로는 jpa나 jdbc 등의 데이터 엑세스를 위한 의존성(ex. spring-boot-starter-data-jpa or spring-boot-starter-jdbc)을 추가하고 그에 따른 DataSource를 추가하기 때문에 큰 문제없이 사용이 가능하다.
하지만 과제 테스트와 같이 특수한 경우에는 DataSource를 활용하지 못하니, 위의 의존성을 쓰지 않고도 spring-tx 모듈을 추가시켜서 사용할 수 있다.
implementation ("org.springframework:spring-tx")

Primary / Replica

• DB를 안전하게 관리하는 방법. DB의 데이터는 훼손가능성이 존재한다.
  DB간 데이터의 불일치가 발생할 경우를 대비해서 읽기 전용 DB와 쓰기전용 DB를 분리해
  쓰기전용 DB를 카피(데이터 변경을 추적)하는 읽기전용 DB를 다수 두는 방식으로 운영.
  이렇게 되면 부하도 분산되고 안전한 운영이 가능하다.

• Primary : 쓰기전용 DB (@Transactional(readOnly = false))
  Replica : 읽기전용 DB (@Transactional(readOnly = true))

• 이렇게 되면 Primary가 데이터 쓰기 도중 문제가 생겼을 때,
  Replica 중 하나가 문제생긴 Primary를 대체해서 다시 운영할 수 있게 된다.