Transaction 트랜잭션
트랜잭션 은 데이터베이스를 이용할 때 두 개 이상의 작업이 영향을 받는 경우 필요
⇒ 스프링에서 XML 이나 어노테이션만으로 트랜잭션이 처리된 결과 도출 가능
ACID PRINCIPLE
- Atomicity ( 원자성 ) 하나의 트랜잭션은 모두 하나의 단위로 처리되어야함
⇒ 트랜잭션이 A와 B로 구성된다면 A와 B의 처리 결과는 동일한 결과여야함
즉 A는 성공, B는 실패일 경우 A,B 둘다 모든 것이 처리전으로 돌아가야함
- Consistency ( 일관성 ) 트랜잭션이 성공했다면 데이터베이스의 모든 데이터는 일관성을 유지해야함
⇒ 트랜잭션으로 처리된 데이터와 일반 데이터 사이에 차이가 전혀 없어야함
- Isolation ( 격리 ) 트랜잭션으로 처리되는 중간에 외부에서의 간섭은 없어야함
- Durability ( 영속성 ) 트랜잭션이 성공적으로 처리되면, 그 결과는 영속적으로 보관되어야함
bankTransfer (계좌 이체) 하나의 트랜잭션을 비즈니스 계층에 정의되면
영속계층에서 withdraw ( 출금 ) 과 deposit ( 입금 ) 이라는 메서드로 정의했을 때
트랜잭션으로 관리한다 혹은 트랜잭션으로 묶는다 라고 표현
⇒ ‘AND’ 연산과 유사
데이터베이스 설계 ( 정규화 )
💩 정규화란?
데이터 저장의 효율을 올리기 위해서
테이블을 늘리고, 각 테이블의
데이터 양을 줄이는 것
정규화를 진행하면서 원칙적으로 칼럼으로 처리되지 않는 데이터
- 시간이 흐르면 변경되는 데이터 → 생년월일은 칼럼으로 사용 but 현재 나이는 사용 X
- 계산이 가능한 데이터 → 주문과 주문 상세가 별도의 테이블로 분리되있다면 사용자가 한 번에 몇 개의 상품을 주문했는지는 칼럼으로 사용 X
- 누구에게나 정해진 값을 이용하는 경우 데이터베이스에서 취급 X → 2022년 1월 1일이 몇요일이였는지 이 사실은 동일한 시간대를 사용하는 모든 사람들에게 통용됨 ⇒ 데이터베이스 기록 X
정규화가 중요한 이유
트랜잭션이 많이 일어나지 않음
⇒ 정규화가 될 수록 테이블은 점점 순수한 형태가 되어감 = ‘트랜잭션 처리’ 대상에서 멀어짐
but 동시에 쿼리문을 통해 필요한 데이터를 가져오는 것이 불편해짐
⇒ join 이나 subquery 이용 증가
결론 : 정규화가 너무 과해도 좋지 않음 ( 쿼리 성능 저하 )
Spring 에서는 @Transactional 을 통해 트랜잭션 지원
전파 (Propagation) 속성
격리 (Isolation) 레벨
Read - only 속성
true 인 경우 insert , update , delete 실행 시 예외 발생, 기본 설정은 false
Rollback - for - 예외
특정 예외가 발생 시 강제로 Rollback
No - rollback - for - 예외
특정 예외의 발생 시에는 Rollback X
@Transactional 의 priority
Method ⇒ Class ⇒ Interface