사용자가 게시물을 작성할 때의 트랜잭션 처리

📎  글또 6기 포스팅

1. 미치도록 더웠던 7월의 회고

 

2. 사용자가 게시물을 작성할 때의 트랜잭션 처리

 

3. Spring AOP - (1) 프록시 패턴, 데코레이터 패턴

 

4. [MySQL] - 트랜잭션의 격리 수준(Isolation level)

 

5. Spring AOP - (2) AOP 개념 및 실습

 

6. 인텔리제이(IntelliJ) - 디버깅(Debugging) 하기

 

7. [Java, 디자인패턴] - 싱글턴 패턴(Singleton Pattern)

 

8. 월간 코드리뷰 Ver_0.1: 커리어 성장 CODE 세미나 정리

 

9. 포스트맨(API 테스트) 활용하기

 

10. 뜻깊은 2021년 회고

 

---

 

안녕하세요, 얼마 전 면접에서 다음과 같은 질문을 받은 적이 있었습니다.

 

"사용자가 게시물을 작성하고, 파일 업로드를 한 후 저장을 할 때 트랜잭션을 어떻게 처리해 주는 것이 좋을까요?"

 

위와 같은 질문에 대해 무엇이 좋은 방법일까? 라는 고민은 해 본 적이 없었던 것 같습니다.

그러던 중 Real MySQL 도서의 트랜잭션 부분을 읽게 되었고, 해당 챕터에서 위 질문에 대한 답을 알 수 있었습니다.

 

따라서 해당 포스팅은 도서의 내용을 바탕으로 작성하였습니다 😃

 

 

📎  트랜잭션

트랜잭션은 작업의 완전성을 보장해주는 것을 의미합니다.

즉, 논리적인 작업셋을 모두 완벽하게 처리하거나 또는 처리하지 못할 경우에는 원 상태로 복구해서

작업의 일부만 적용되는 현상(Partial Update)이 발생하지 않게 만들어주는 기능입니다.

 

트랜잭션이란 개념의 예제로 은행 입출금 문제로 많이 비유를 하곤 합니다.

 

예를 들면 다음과 같습니다.

은행 입출금

1. A라는 은행에서 B라는 은행으로 송금을 하는 상황입니다.

2. A -> B로 송금하는 도중 오류가 발생하여 A은행 계좌에서는 출금이 되었지만, B은행 계좌에는 입금이 되지 않았습니다.

3. 이때 해결할 수 있는 방법은 A은행 계좌의 출금을 취소하거나, 출금된 금액만큼 B은행 계좌에 입금을 시켜주면 됩니다.

4. 하지만, 3번의 방법은 더 번거로울 뿐더러 만약 또다시 오류가 발생한다면? 더 심한 오류를 야기할 수 있습니다.

5. 따라서, 위와 같이 A은행 계좌의 출금과 B은행 계좌의 입금 모든 거래가 성공적으로 끝나야

이를 완전한 거래로 인정하고(작업의 완전성), 거래를 하는 도중 오류가 발생했다면 해당 거래를 하기 전으로 되돌립니다.

6. 5번과 같이 거래(작업)의 안정성을 보장해주는 방법이 트랜잭션입니다.

7. 데이터베이스의 관점에서는 데이터를 입력, 갱신, 삭제 등의 CRUD 작업을 하는 도중

오류가 발생하면 작업 전의 원상태로 되돌립니다.

8. 데이터베이스의 처리 과정이 완전히 보장되었을 때만 최종적으로 데이터베이스에 반영을 합니다.

트랜잭션에 대한 설명은 간단히 하고 다음으로 넘어가겠습니다 😂

 

트랜잭션에 대한 추가 설명은 아래 블로그를 참고해주세요 :)

• https://coding-factory.tistory.com/226
• https://brunch.co.kr/@skeks463/27

 

 

 

 

📎  사용자가 게시물을 작성할 때의 트랜잭션 처리

포스팅의 제목에 대해 정리를 해보겠습니다. 상황은 다음과 같습니다.
'사용자가 게시판에 게시물을 작성(첨부파일 업로드)한 후 저장 버튼을 클릭했을 때 서버에서 처리하는 내용'

(실제로는 아래 내용보다 훨씬 복잡하겠지만, 단순화한 과정입니다.)

트랜잭션 처리

1) 처리 시작

  - 데이터베이스 커넥션 생성

  - 트랜잭션 시작

2) 사용자의 로그인 여부 확인

3) 사용자의 글쓰기 내용의 오류 여부 확인

4) 첨부로 업로드된 파일 확인 및 저장

5) 사용자의 입력 내용을 DBMS에 저장

6) 첨부 파일 정보를 DBMS에 저장

7) 저장된 내용 또는 기타 정보를 DBMS에 조회

8) 게시물 등록에 대한 알림 메일 발송

9) 알림 메일 발송 이력을 DBMS에 저장

  - 트랜잭션 종료(COMMIT)

  - 데이터베이스 커넥션 반납

10) 처리 완료

위 처리 과정에서 DBMS의 트랜잭션 처리에 좋지 않은 영향을 끼치는 부분을 나눠서 살펴보겠습니다.

• 데이터베이스의 커넥션을 생성하는 코드를 1번과 2번 사이에 구현합니다. 그리고 9번과 10번 사이에서 트랜잭션을 COMMIT하고 커넥션을 종료(또는 커넥션 풀로 반납)합니다. 실제 DBMS에 데이터를 저장하는 작업(트랜잭션)은 5번(사용자의 입력 내용을 DBMS에 저장)부터 시작이 됩니다. 따라서 2번과 3번의 과정이 아무리 빨리 처리가 된다고 하더라도 DBMS의 트랜잭션으로 포함시킬 필요는 없습니다. 보통 데이터베이스 커넥션은 개수가 제한적이기 때문에 각 단위의 프로그램이 커넥션을 소유하는 시간이 길어질수록 사용 가능한 여유 커넥션의 개수또한 줄어들 것입니다. 그리고 어느 순간에는 각 단위의 프로그램에서 커넥션을 가져가기 위해 기다려야 하는 상황이 발생할 수 있습니다.

 

• 위 과정에서 더 위험한 부분은 8번 작업인 '게시물 등록에 대한 알림 메일 발송' 입니다. 메일 전송이나 FTP 파일 전송 작업 및 네트워크를 통해 원격 서버와 통신하는 작업은 DBMS의 트랜잭션 내에서 제거하는 것이 좋습니다. 프로그램이 실행되는 동안 메일 서버와 통신할 수 없는 상황이 발생한다면 웹 서버뿐만 아니라 DBMS 서버까지 위험해지는 상황이 발생할 수 있기 때문입니다.

 

 

따라서 위 처리 과정에서 필요한 DBMS의 작업은 다음과 같습니다.

• 사용자가 입력한 정보를 저장하는 5번과 6번 작업은 반드시 하나의 트랜잭션으로 묶습니다.
• 7번 작업은 단순 데이터의 확인 및 조회이므로 트랜잭션에 포함할 필요는 없습니다.
• 9번 작업의 경우 조금 성격이 다르기 때문에 이전 트랜잭션(5번, 6번)과 묶지 않고 별도의 트랜잭션으로 분리하는 것이 좋습니다.

 

 

위의 내용들을 적용해서 처리 과정을 다시 설계해보면 다음과 같습니다.

트랜잭션 처리

1) 처리 시작

2) 사용자의 로그인 여부 확인

3) 사용자의 글쓰기 내용의 오류 여부 확인

4) 첨부로 업로드된 파일 확인 및 저장

  - 데이터베이스 커넥션 생성(또는 커넥션 풀에서 가져오기)

  - 트랜잭션 시작

5) 사용자의 입력 내용을 DBMS에 저장

6) 첨부 파일 정보를 DBMS에 저장

  - 트랜잭션 종료(COMMIT)

7) 저장된 내용 또는 기타 정보를 DBMS에 조회

8) 게시물 등록에 대한 알림 메일 발송

  - 트랜잭션 시작

9) 알림 메일 발송 이력을 DBMS에 저장

  - 트랜잭션 종료(COMMIT)

  - 데이터베이스 커넥션 종료 또는 커넥션 풀에 반납

10) 처리 완료

물론 위의 예제가 최적의 트랜잭션 설계는 아닐 수 있으며, 업무 요건에 따라 달라질 수 있습니다.

위에서 설명하려는 바는 프로그램의 코드가 데이터베이스 커넥션을 가지고 있는 범위와 트랜잭션이 활성화되어 있는 프로그램의 범위를 최소화 해야 한다는 것입니다.

또한 프로그램의 코드 라인 수는 한두 줄 이더라도, 메일 전송이나 FTP파일 전송 등의 네트워크 작업이 있는 경우 반드시 트랜잭션에서 배제를 해 주어야 합니다.

위와 같은 실수로 인해 DBMS 서버가 높은 부하 상태로 빠지거나 위험한 상태에 빠지는 경우가 빈번히 나타난다고 합니다.