리마큐에서 트랜잭션은 짧게 유지하는게 좋다 => 트랜잭션을 오래 점유하고 있으면 언두로그에 로그가 쌓이고 이게 성능저하로 이어지기 때문에
그럼 스프링부트 서버에서는 어떻게 트랜잭션을 짧게 해야하나 생각해보다가 내 대가리론 해답이 안떠오름..
1. 서비스 레이어에서 @Transactional 어노테이션을 써서 처음 커넥션풀에서 커넥션을 할당받고, 해당 메소드 안에 있는 내용중 트랜잭션이 또 필요하다면
다른 클래스의 @Transactional 메소드를 사용해서 내부 트랜잭션을 사용 => 이렇게 하면 트랜잭션 전파 속성 기본이 Required니까 동일한 커넥션을 사용하는 것에서 이점이 있지만 실질적인 물리 트랜잭션의 유지 기간은 내부 트랜잭션을 사용하든 사용하지 않든 똑같다고 느낌
2. 그럼 퍼사드 서비스 레이어를 만들고 이 레이어의 메소드에는 @Transactional이 없게 만든 후 각각 서비스 레이어들을 DI 받아서 따로따로 트랜잭션을 적용시키는것. 이게 2번째로 생각한 방법인데. 이렇게 하면 각각의 @Transactional가 붙은 메소드는 따로 분리되어 있기 때문에 별도의 커넥션을 사용한다고 느낌. 이렇게 하면 데이터베이스에서의 트랜잭션 점유 문제를 해결할 수는 있겠지만 커넥션풀의 사용과 반납을 반복해야 한다는 점에서 비효율적이라고 생각함..
내 대가리론 딱 이정도만 생각나는데 어떻게 해야 트랜잭션 점유시간도 줄이면서 동일한 커넥션을 사용할 수 있음??
트랜잭션 aop를 사용하지 않고 로우레벨로 가야되나 이런문제는..
맞이하는 문제마다 다르다 억지로 트랜잭션을 짧게 가져가라는게 아님
같은 트랜잭션이어야하면 필연적으로 같은 트랜잭션르로 묶는게 맞음
ㅇㅇ 같은 트랜잭션으로 묶이는게 필수적이면 어쩔수 없는데, 딱 리마큐에서 "트랜잭션 점유시간은 가능한 짧게 잡는게 좋다" 이것만 생각했을 때 나온 문제임..
ddd is good - dc App
비즈니스 로직 자체가 최소한의 트랜잭션으로 쪼갠거라면 트랜잭션 점유시간을 애초에 어떻게 동일한 커넥션 안에서 점유시간을 줄이지..? 1. 쿼리 최적화 2. 외부 API 트랜잭션에서 호출하지 않기 3. 실시간성이 중요하지 않은 데이터라면 이벤트 발행으로 비동기 처리 정도가 생각나는데...
아 아니면 JPA를 사용할 때 OSIV가 활성화되어 있다면 프레젠테이션 레이어까지 커넥션 범위가 넓어지기 때문에 점유시간이 길어질 수 있움