Spring @Transactional propagation 정리

-

 Spring 에서는 총 일곱가지의propagation 옵션을 제공한다.

@Transactional  로 묶인 함수나 클래스에서 excpetion 이 발생하면 rollback이 된다. 하지만 스프링에서 제공하는 noRollbackFor, noRollbackForClassName, rollbackFor, rollbackForClassName 같은 옵션을 통해 이 역시 설정 할 수 있다.


1.REQUIRED

물리적 transaction 이 없으면 만든다. 이미 존재하면 그 transaction 에 참여한다. 그리고 각각의 @Transactional REQUIRED 로 설정된 메소드 들은 논리적 transaction 을 갖는데, 각각 경계를 가지고 있고, 저마다 범위가 있다. 


모든 transaction 이 하나의 물리적 transaction  에 매핑되기 때문에 그중 하나라도 논리적 transaction 이 실패하게 되면 rollback  모든 그 물리적 transaction 에 있는 논리적 transaction 들이 rollback 된다.

바깥에서 catch 해서 처리 한다 하더라도 여전히 transaction 은 rollback 된다. 이미 실패된 논리적 transaction 에서 rollback-only marker 라는것을 세팅 해버리기 때문이다. 이렇게 되면 같은 물리적 transaction 에 있는 것들은 rollback 될수밖에 없다.


2.REQUIRES_NEW

이는 이름에서처럼, 스프링이 항상 새로운 물리적 transaction 을 만들도록 한다. 그렇기 때문에 바깥의 물리적 transaction 의 속성(timeout, isolation level, readonly)을 상속받지 않는다. 

각각의 물리적 transaction 은 각각의 database connection 을 필요로 한다는것을 염두해야 한다. 예를 들어 메소드 A 가 메소드 B 를 호출했는데, B 가 REQUIRES_NEW 로 열렸다면, B 가 끝날때까지 A 는 connection 이 오픈 된 상태로 B 가 끝날때까지대기하게 된다. 


이 경우 B 가 Runtime Exception 을 호출하면 caller 인 A 역시 rollback 되지만(because exception is propagated to A), try-catch 로 Runtime Exception 을 막으면, A 의 transaction 은 rollback 되지 않고 commit 된다.  마찬가지로 B 가 commit 되고 난 뒤 A 가 rollback 되더라도 B 의 commit 은 영향 받지 않는다. 


3.NESTED

NESTED 는 1번 REQUIRED 와 유사하게 행동한다. 다른점은,  savepoint 라는것을 사용한다는 것이다. 내부의 논리적 transaction 이 caller 의 logical transaction 과 무관하게 rollback 될 수 있다.

Hibernate JPA 는 NESTED 옵션을 지원하지 않는다.


4.MANDATORY

이 옵션은, 이 메소드 혹은 클래스까지 오기 이전에 기존에 물리적 transaction 이 반드시 존재해야한다. 그렇지 않으면 exception  을 발생시킨다. 존재 한다면, 그 물리적 transaction 에 참여하게 되며, 이 후 동작은 REQUIRED와 같이, callee 가 에러를 발생시키면, caller 에서 발생한 작업 역시 rollback 된다. 


5.NEVER

4번 옵션과 달리, 이 메소드 혹은 클래스가 실행될때, 이전에 존재하는 물리적 transaction  이 반드시 없어야 한다. 존재하면 exception  을 발생시킨다. 


6.NOT_SUPPORTED

이 메소드 혹은 클래스가 실행될 때, 기존에 물리적 transaction 이 있으면, 그것을 일시 중지 시키고,  어떠한 물리적 transaction 과 상관 없이 떨어져서 작업을 수행한다. 이때 DB 작업이 필요하다면, REQUIRED 형태로 새로운 별도의 물리적  transaction  을 생성하여 작업을 하고, 이 메소드 혹은 클래스가 종료 되면, 기존의 suspend 되었던 transaction  을 resume  시킨다. 이때, 따로 떨어져 작업했던 결과가 exception 을 발생시켰다면, 이 역시 propagate 되어 caller 역시 rollbakc 된다.


마찬가지도, suspend 된 기존 DB connection  역시 active  상태로, 쓰이지 못하며 대기하게 되므로, 잘 관리해야 한다. (오래 걸리지 않도록 해야한다.)

7.SUPPORTS

기존에 물리적 transaction 이 존재한다면, 경계선을 긋고 논리적 transaction 으로 그 물리적 transaction 에 참여한다. 기존에 존재하는게 없으면, 그냥 수행한다.


caller 가  REQUIRED 이고, callee 가 SUPPORTS 라고 생각해보자. REQUIRED 는 물리 transaction 을 만든다. callee  가 수행될땐, 이미 물리 transaction 이 있으므로, 여기에 join 한다. 이때 실패하게 되면, rollbakc 하고, caller 의 transaction 도 rollback 된다. 바깥에서 try-catch  를 해도, 이미 안에서 rollback-only marker 를 찍었고 동일한 물리 transaction 이기 때문에 어쩔수 없다.


만약 caller 가 아무런 annotation 이 없고, callee 가 SUPPORTS 라고 해보자. 이 경우 caller 는 물리적 transaction 없이 작업을 수행한다. 만약 DB 세팅하는 순간이 오면, 기본값이 REQUIRED 에 의해 스프링은 물리 transaction 을 생성하고, insert 같은 작업을 할것이고, commit 을 할 것이다. 그리고 callee 를 부르게 되면, callee 입장에서는 기존의 물리적 transaction 이 없으므로 joni 할 transaction 이 없고, 그렇다고 따로 만들지도 않는다. save 같은 함수를 호출하게 되면, 그저 스프링의 기본값인   REQUIRED 로 물리적 transaction  을 만들고, commit 하고 닫는다. 만약 callee 가 runtime exception 을 발생시킨다고 해도, 이미 뭐 처리할 물리적 transaction같은게 없으므로, 아무런 rollbackk 도 일어나지 않는다. 


참조 : https://dzone.com/articles/spring-transaction-propagation

Comments

Post a Comment

Popular posts from this blog

삼성전자 무선사업부 퇴사 후기

-
"잠깐 드릴 말씀이 있는데요."  8월 어느날. 갑작스런 내 메신저에, 이미 예상을 하셨는지도 모르겠다. 몇주간 보인 내 근무 태도와, 먼저 메신저로 이런말을 하는 적이 한번도 없는 내가 면담을 요청한거나 마찬가지니. 갑자기 죄송스럽지만, 퇴사를 하겠다고 말씀을 드렸다. 신입사원으로 입사한지 6년 반만이었다.  삼성전자. 글로벌 기업이지만. 그래서일까. 우리나라에서 사기업,대기업 하면 가장 많이 사람들의 입에 오르며, 연일 다양한 언론의 주목을 다각도로 받는 기업. 명절에 가족 친지들을 만나면, 어르신들은 항상 요즘 삼성 어떠냐, 라고 물으셨었다. 내가 어떤지보다는. 무선사업부. 사람들 일상에 제일 가까운 핸드폰을 만들기도 하고, 내가 다니던 동안은 성과급 이야기에 무선 이야기가 늘 빠지지 않았다. 많은 사업부들이 있지만, 적어도 내가 입사 할때는 많은 개발직군은 무선이 최우선 지망이었다. 사내 댓상에서 조차, 삼성에는 전자와 후자가 있고, 전자에는 무선만 있습니다 라는 이야기를. 무선이 아닐때 들었었다. 그땐. 부럽기도 하고 어이가 없기도 했는데. 네임밸류  주위에선 잘다니는 회사를 왜 나오려고 하냐고. 그 안이 전쟁이라면 바깥은 지옥이라고. 이런 말들을 해줬었다. 누구나 아는 회사를 다니면 편하다. 아무도 뭐하는 곳이냐고 묻지않는다. 어렵게 설명하지 않아도 된다. 부모님도, 아들 어디 취직했어? 라고 물어오는 질문들에 대답이 편하셨을테다. 모르는 사람에게 소개할때도 편하다. 이직을 준비하는 과정에서도 그랬다. 이런점이 편했고, 알게 모르게 사람들의 이미지에 적어도 밥벌이는 하겠구나 하는 이미지였으리라. 하는 생각이 든다.  인지도 언론의 기사 제목 뽑는 능력 덕분에, 바깥의 사람들은 삼성 직원이 엄청난 연봉을 받는줄 안다. 그러나 안에서는 어떻게 하면 돈을 더벌까, 더 모을까 이런 이야기들을 한다. 집을 사지 못해 전세를얻고, 회사 앞 수많은 오피스텔에서 다니는 사원들중 본인 소유인 사람은 얼마나 되려나. 임직원중에 부자들...
Read more

개발자 커리어로 해외 취업, 독일 이직 프로세스

-
요즘은 국내 IT 기업도 이런 프로세스를 많이 따라가고 있는것 같다. 아래는 내가 해외 이직을 목표로 준비하면서 밟았던 몇몇 프로세스 경험을 종합했다. 0.  최초 컨택 크게 두가지 경로가 있는데, 링크드인에 프로필을 업로드하고 관리를 하다보면 연락이 오는경우. 그리고 내가 직접 링크드인에서 지원을 하거나 회사 홈페이지의 오픈 포지션에서 지원을 하는 경우이다.  링크드인에 프로필을 업로드하고 관리를 하다보면, 메세지를 받게 된다. 두가지의 경우가 있는데, 하나는 헤드헌터로부터 받는 경우, 그리고 하나는 채용하는 회사의 HR 로부터 받는 경우이다.   헤드헌터의 경우 채용하는 회사의 이름이나 구체적인 정보를 오픈하지는 않는다. 자신의 고객이 인재를 구하고 있는데 너의 프로필이 매칭되는것 같다, 괜찮다면 짧게 소개하고 이야기를 하고싶다, 라는 식이다. 회사의 리크루터가 직접 컨택하는 경우도 있는데, 이때는 보통 팀 소개도 간략히 해주기도 한다. 우리회사의 이런 팀에서 어떤인재를 찾고 있는데 너의 프로필이 잘 어울리는것 같다. 전화를 통해 자세한 이야기를 하고싶다, 라고 온다.  처음엔 몰랐지만, 몇번 메세지를 받다보니 내용은 복붙하고 이름만 바꿔서 뿌리는것 같은 느낌이다. 내가 조건을 필터링해서 구인공고를 검색할 수 있듯이, 리쿠르터들도 키워드를 검색해서 매칭되는 프로필들에게 뿌릴 수 있는것 같다. 운좋게 가고싶었던 회사 인사팀으로부터 연락이와서 정성스레 답장을 보냈는데, 그 뒤로 아무런 응답이 없는 경우도 있었다. 직접 지원을 하는 경우에도,  끝끝내 답장이 오지 않는 경우가 더 많았던것 같다.  1. 첫번째 인터뷰 첫번째 인터뷰는 주로 전화 혹은 스카이프로 짧게 진행되었다. 헤드헌터나 인사팀과 서로 소개하는 식이었다. 주로 받는 질문은 이런것이었다. - 왜 한국을 떠나려고 하는지 - 왜 삼성을 떠나려고 하는지 - 여기서 일하는데 비자를 갖추고 있는지 - 일을 한다면 언제부터 일할 수 있는지 그러면서 ...
Read more

코드리뷰에 대하여

-
우리 개발팀에는 DoR, DoD,DoP 라는 것이 있다. 이전에는 겪어본적이 없는것들이다. 나중에 따로 정리를 하겠지만, 우선은 코드리뷰에 대해 정리를 해보려고 한다.  이전 회사에서도 코드리뷰가 있었다. 처음부터 있었던건 아니고, 나중에 생겼다. 하지만 반드시 reviewer 가 accept 해야 commit 이 되는것도 일부 모듈에 대해서만 적용되었기 때문에 모든 code commit  에 대해 approval  이 필요하지 않았다. 때로는 빨리 검증 받고 배포해야 하는데 review 안되서 이게 걸림돌이라는 느낌이 강했고, 어떤 경우엔 담당자가 나 혼자여서 review 를 해줄 사람이 없었다. 모듈별로 주담당-백업이 나뉘어 있었는데, 백업 모듈에 대해 review 를 하기엔 잘 알지 못하고, 주담당인 모듈에 대해선 누군가 review  를 해줘야하는데 오래 걸리니 걸림돌이 되고. 백업이 없는 경우는 review 가 없는 상황. code reivew  에 대한 인식이 없다가 생긴것은 좋았으나, 그것이 개발에서 꼭 필요한 일부분이라기 보단 형식적인 통과의례로서 병목처럼 여겨졌다. 여기서는 아니다. review 를 받지 못하면 merge 되지 않는다. 우리 팀은 이제 7명. 옆 팀은 더 많다. 한 9명 되나? frontenf, backend 가 한 팀에 있고,  내 모듈, 네 모듈의 개념이 아닌, 우리 팀의 모듈이다. 그래서 특별히 어려운 티켓을 제외하면 누구나 develop, review, test 를 할 수 있게 되어있다.  reviewer  를 찾는 문화도 있다. daily  에서, 혹은 팀 채널에서 티켓 개발이 끝났으니 reviewer  를 찾고 있다, 라든지, 지금 할거 없는데  도움 필요한 사람? 이런식으로 나서기도 한다.  review 도 대충하지 않는다. 철저하다. 여러번 퇴짜를 맞았다. 나도 마찬가지로 적극적으로 의견을 내려고 한다. 아무리...
Read more