스프링 DB 트랜잭션

Question

저희 쪽 프로젝트는 트랜잭션이 서비스의 메소드 하나당 하나씩 생성되도록 세팅되어 있는데이 때문에 컨트롤러에서 여러 서비스를 호출하게 되면 트랜잭션이 계속 생성되어 오버헤드가 발생하고DB lock이 생길 수 있다면서 모든 작업을 한 메소드에 밀어넣고 실질적으로 컨트롤러가 하는 역할은서비스 메소드 호출 하나밖에 없게 하도록 구현하고 있는데 컨트롤러 메소드에 서비스 호출문 단 한 줄만 들어가는 형태가 올바른 구조인지 잘 모르겠습니다.(정말 단 한 줄입니다. 모든 컨트롤러의 메소드가 이런 형태로 구현되어있습니다.)이에 대해서 이의를 몇 번 제기하긴 했는데 당장 이런 형태의 코드가 문제를 만들진 않아서 반박하기 애매합니다.좀 두서없지만 요약하자면컨트롤러와 서비스에선 각각 어떤 로직을 처리해야 할까요? 저는 적어도 지금처럼 모든 로직을 서비스에서 처리하는건 옳지 않다고 생각합니다.저는 트랜잭션은 최대한 나눌 수 있다면 나누는게 좋다고 배웠던 거 같은데 지금은 모든 트랜잭션을 하나로 묶어서 처리하고 있습니다. 어느 쪽이 옳은 방향일까요?

초무쿤 · Accepted Answer

&#64;Transactional이 여러번 거쳐간다고 디른 커넥션을 사용하는건 아닙니다.(처음 오픈된 커넥션이 재사용됨)중첩 트랜잭션(N개)이라도 묶여있다면 커넥션은 1개로 처리됩니다.(&#64;Transactional 5개를 통과해서 5개 Transaction객체가 생기지만 Conneciton 은 최초 획득한 Connection이 재사용됨)확인해보시려면 Datasource 의 getConnection에 브레이크 포인트 걸어보시면 됩니당.고로 Controller에서 여러 서비스를 호출한다고 오버헤드 걸리거나 하진 않구요.전 &#64;Transactional 어노테이션을 controller단에 정의하는 편인데요.Controller에서 여러 서비스 호출하는데 좀 문제가 생길수도 있고 웹아플리케션이 아닌곳에서 Service컴포넌트들 재활용하는 케이스가 있어서..질문하신 이유가 트랜잭션 문재라기 보단컨트롤러 - 서비스 1대1로 잡는 아키텍쳐가 맞냐(트랜잭션 이유로)인듯 한데요.전 님 의견에 동의해요~화면에 관련된 로직들은 칸트롤러에서 여러 서비스 호출해서 처리하는게 밎다고 봅니다.뷰에서 요구하는 스팩을 Controller에서는 bypass만 하고계속 Service에 추가하게 되면화면 추가될때마다 비슷비슷한 서비스들이 계속 추가되서도메인이 오염된다고 봐서요.(물론 서비스 규모에 따라 다를듯합니다. 업무처리시스템이냐 일반 어플리케이션에 따라 다를듯.)ps. 근데 팀원이시면 아키텍쳐 정책대로 그냥 하세요 ㅎ;엄창 벅잡한 업무시스템 아니면 뭐 크게 달라질거도 없을거에요.

매일매일새로워 · Answer

트랜잭션 설정 기본으로 되어있으면 어차피 트랜잭션 전파로 인해서 여러 메서드여도 트랜잭션 하나로 묶어서 처리되지 않아요..?

카카오콘 · Answer

트랜잭션이 겹치면 설정 내용에 따라 자기가 알아서 처리합니다.대부분 기본값으로 놓고 쓰실텐데, 그럼 부모트랜잭션이 돌고 있을 때 자식 트랜잭션이 있으면 부모 트랜잭션에 흡수됩니다.이거 트랜잭션 상태 보는거 설정 켜시면 바로 보실 수 있는데 대체..?그리고 밑에 글에 답변을 드려보자면만드는 사람이랑 처음 만들 때 참여했던 사람들 한정 코드 이해가 굉장히 편하지만, 인수인계 받을 사람은 지옥을 볼 것 입니다.어떻게 하는게 좋냐라는 질문에 대한 답은... 당연히 정답은 없습니다만 컨트롤러에 비즈니스 로직이 들어가는건 지양하는게 맞고, 대부분의 개발 로직 상 컨트롤러와 메소드가 1:1 매핑되는경우도 많습니다만, 컨트롤러 / 서비스가 분리된건 좋은데 서비스 내 메소드 하나에 몰빵이라고 한다면 첫줄에 적은 말이 답변이 되겠네요.나눠도 결국 조건에 따라 합쳐집니다. 트랜잭션을 쪼개는게 중요한게 아니라, 어디까지 하나의 트랜잭션으로 돌아야 하는지 구분하는게 핵심이죠.

양반후반 · Answer

애초에 스프링에서 제공하는 @Transactional을 사용하지 않고 AspectJExpressionPointcut 사용해서 관리 하는 구조가 잘못된것 같네요.상황에 따라 일부는 별도 트랜잭션으로 해야할 경우도 있고 하나의 트랜잭션에서 해야할 경우도 있는건데 @Transactional을 사용하면 파라미터에 따라 개별 설정이 가능하지만 해당 서비스에서는 그러한 선택권을 전혀 주고 있지를 않아 발생하는 문제같네요.

장독깨기 · Answer

트랜잭션은 최대한 나누는게 아닙니다.가령 주문을 한다. 그럼 여러 테이블에 입력을 할텐데요, 이들을 하나의 트랜잭션으로 묶어야 합니다.그리고, 이 주문이라는 것이 하나의 서비스가 되는거겠죠.그니까, 여러 테이블에 입력하는 각각을 여러 서비스로 나누면 안 됩니다.이 관점으로 보면 전부는 아니겠지만 대부분이 하나의 컨트롤러에서 하나의 서비스를 호출하게 될 겁니다.

에프킬러 · Answer

트랜잭션의 덩치를 너무 크게 하면 그 덩치는 덩치값을 하게되어서하나의 트랜잭션이 건드리는 테이블의 수도 LOCK 의 수도 많아지게 됩니다하나의 트랜잭션 범위에 많은 것을 넣어 놓으면 참 뿌듯해보이지만동시접속이 많아지면 문제가 드러납니다제 생각엔 빼도 큰문제 없는 요소들은 트랜잭션범위에서 빼거나, 비동기서비스로 구현해서최대한 덩치를 줄이는게 맞다고 생각해요트랜잭션들을 잘게 쪼개고 싶다면 Propagation 옵션을 활용해보시기 바랍니다@Transactional(propagation = Propagation.REQUIRES_NEW) 와 같이 하면 부모트랜잭션으로 부터 독립된 자식트랜잭션이 됩니다와 같은

장독깨기 · Answer

흠.. 조금 더 말씀을 드려 보겠습니다.트랜잭션을 크게하고 작게하고 폼나고 말고 이런게 아닙니다.비지니스에 따라 트랜잭션은 정해 지는 겁니다.가령, 주문을 한다고 할때, 간략하게 보면, 재고를 파악하고 주문상품을 입력하고 주문 완료 문자를 사용자에게 보낸다고 해보겠습니다.그럼, 재고를 파악하고 주문상품을 입력하는건 당연히 하나의 트랜잭션으로 묶어야 합니다. 전파를 하든 말든요.이걸 각각의 서비스로 나누면 안된다는 얘깁니다. 그러나, 주문 완료 문자를 보내는건 실패하더라도 주문에는 영향을 안 주니 별도의 서비스로 빼면 됩니다.게시글에 파일첨부기능이 있다면 각각 별개의 서비스로 만드는게 아니라 하나의 서비스로 트랜잭션으로 묶어야 합니다.이런식으로 비지니스에 따라 트랜잭션의 범위는 정해지기 마련입니다. 이래도 되고 저래도 되고 이런게 아니구요.윗 분이 말씀하셨지만, All or Nothing 이건 비지니스에 따라 무조건 지켜야 하고, 그 다음에 성능적인 관점에서 락 등을 해결해야 합니다.

스프링 DB 트랜잭션

7개의 답변

기술 목록