트랜잭션 격리 수준
Read Uncommitted
- 트랜잭션의 처리 중 데이터나 아직 commit되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용
- 트랜잭션이 ROLLBACK 되는 상황에서 그 전에 다른 트랜잭션에서 정보를 읽었다면 그 정보를 가지고 데이터를 처리함
- Dirty Read 라고 함
Read Committed
- 트랜잭션이 수행되는 동안 다른 트랜잭션이 변경된 데이터에 접근할 수 X, Commit이 이루어진 트랜잭션만 조회 가능
- 트랜잭션이 작업중에 다른 트랜잭션이 조회를 하면, 작업 전 값이 가져와짐
- NON-REPEATABLE READ 문제 발생
- 한 트랜잭션 내에서 같은 조회 명령을 실행할 때 값이 달라질 수 있음
- 이는 트랜잭션 내 동일한 SELECT 쿼리를 실행할 때 항상 같은 결과를 보장해야한다는 “REPEATABLE READ” 정합성에 어긋남
- ex) 12시에 입출금 내역을 조회한다고 할 때 SELECT 할때마다 값이 바뀌어서 원하지 않는 결과가 도출
Repeatable Read
- 트랜잭션이 ROLLBACK될 가능성에 대비해 변경되기 전 레코드를 Undo 영역에 백업해두고 실제 값을 변경 → MVCC(Multi Version Concurrency Control)
- Repeatable read에서는 같은 트랜잭션은 동일한 Undo 영역을 조회할 수 있도록 보장
- “PHANTOM READ” 문제 발생 가능(ex. SELECT * From table FOR UPDATE 과정에서 쓰기 과정을 위해 UNDO가 아니라 실제 데이터를 가져오기 때문에 이후 실제 UPDATE 실행 시 새로운 데이터가 업데이트 돼서 같이 나올 수 있음)
SERIALIZABLE
- 읽거나 쓰는 작업에서 레코드의 데이터에 다른 트랜잭션이 접근 불가
- 동시성이 매우 떨어짐
JWT
- 유저를 인증하고 식별하기 위한 토큰(Token)기반 인증
- 세션과는 탈리 클라이언트에게 저장, 이로인해 서버의 부담을 덜 수 있음
- 토큰 자체에 사용자의 권한 정보, 서비스를 사용하기 위한 정보가 포함됨
- 토큰이 발급하고 사용자 정보를 변조하더라도 토큰을 재발급하지 않는 이상 반영되지 않음
진행 순서
- 클라이언트 사용자가 아이디, 패스워드를 통해 웹서비스 인증
- 서버에 서명된 JWT를 생성해서 클라이언트에게 응답으로 돌려줌
- 클라이언트가 이후 서버에게 데이터를 요청할 때 JWT 첨부
- 서버에서 클라이언트로부터 온 JWT를 검증
구성 : Header + Payload + Signature
- Header : 토큰의 타입, 암호 알고리즘
- Payload : 사용자, 토큰에 대한 속성을 key-value형태로 저장, 이곳에 개인을 식별하는 민감한 정보는 넣으면 안됨
- Signature : Header와 Payload, secret key를 공개키로 암호화 해서 서버로 전달
장점
- 서버에서 사용자 데이터를 저장하지 않아도 된다.
- 토큰 자체에 권한이 담겨있다
- 토큰 생성 방법만 공유하면 도메인이 다른 여러 서비스에서 같이 활용할 수 있다. (세션은 세션테이블을 서비스들이 공유해야함)
- 토큰 인증을 위한 I.O가 발생하지 않는다.
단점
- 토큰 탈취시 만료될 때까지 인증을 제한할 방법이 없다. (세션은 세션테이블을 초기화 하면 됨)
- 통신에 주고받아야 할 데이터가 많아진다. (base64 방식)