티스토리 뷰

728x90

트랜잭션은 원자성을 가지는 하나의 task의 단위라고 생각할 수 있다. 트랜잭션은 로직 작성에 아주 중요한 요소이기 때문에 많은 고민이 필요하다. 

트랜잭션을 엄격하게 적용하면 모든 것이 좋아 보이기는 하지만 모든 일이 그렇듯 tradeoff가 발생하기 마련이다.

1. 트랜잭션이 길어지면 DB Locking이 발생하기 쉽다. 하나의 트랜잭션이 끝날 때 까지 해당 테이블을 놓지 않는다.

2. DB Locking이 길어지면 DB 컨넥션이 full이 되고 심한 경우는 서버가 죽을 수 있다.

 

일반적으로 트랜잭션을 거는 이유는 하나의 task의 원자성을 보장하기 위한 것으로, 특정한 작업 중에 관련된 정보가 변경되는 경우 예상하지 못하는 결과가 나올 수 있기 때문이다.

 

부작용이 있기 때문에 최소한의 단위로 사용하는 것이 필요하다. 대안으로는 그 업무에 정확하게 필요한 내용만을 따로 추출하여 최소한의 의존성을 가지도록 새로 구현하는 것이 바람직하다. 얼마나 짧게 테이블을 쥐고 있게 하는가의 문제이다.

 

- 더 중요한 것은 트랜잭션이 꼭 필요한지 고민이 필요하다. 

예를 들면, 도어락의 키서버의 경우는 일반적으로 OTP코드를 기반으로 만들어지는데 사실 이전의 상태를 알 필요가 없다. 따라서 관련된 정보가 많이 있다하더라도 OTP에 생성에 필요한 몇 가지 인자만 주어지면 되기 때문에 트랙잭션의 문제를 크게 고민할 필요가 없다. 

 

- 현업에서 많이 발생하는 문제는 서버가 죽고 결과의 에러를 줄이든가 아니면 서버는 버티지만 많은 에러를 받을 들일 수 있는가의 문제이다. 대부분의 문제는 트랜잭션을 포기하면 된다. 정말 중요한 트랜잭션은 많지가 않다. 돈이나 사람의 생명에 관련되는 문제를 제외하면 그렇게 많지가 않다. 

- 진짜 트랜잭션이 중요한 문제라면 그 기능에 대한 코드를 심플하게 다시 만드는 것이 좋고 여러 개의 테이블을 조인해야 한다면 그 기능을 위해서 별도의 테이블 설계를 하는 편이 더 낫다.

 

 

728x90
댓글