[Spring] 트랜잭션 서비스 추상화토비의 스프링에서 나오는 트랜잭션 서비스의 추상화는 지금까지도 활용되고 있으며 스프링부트 환경에서도 가장 중요한 핵심 아키텍처로 활용되고 있습니다. 과거의 복잡한 트랜잭션 코드가 어떻게 @Transactional이라는 하나의 어노테이션으로 관리할 수 있게 되었는지 살펴보도록 하겠습니다.1. 트랜잭션의 시작: 원자성(Atomicity)DB는 단일 SQL에 대해서는 트랜잭션을 보장하지만, 여러 작업을 하나의 단위로 묶는 것은 애플리케이션의 역활입니다. 이 역활은 AI의 개발을 위임하더라도 트랜잭션의 범위 만큼은 백엔드 개발자가 직접 검토해야할 정도로 중요한 작업니다. 예: 은행 송금 로직출금 계좌에서 돈을 뺀다. (UPDATE)-- 여기서 예외 발생! --입금 계좌에 돈..
분류 전체보기
@Servicepublic class ReservationService { public int calculateFinalPrice(int originalPrice, String discountType) { int finalPrice = originalPrice; // 문제 1: 문자열로 타입 구분 → 오타 위험, 타입 안전성 없음 // 문제 2: 모든 할인 로직이 한 곳에 뭉쳐있음 // 문제 3: 매직 넘버(1000, 0.1) 직접 사용 // 문제 4: 정책 추가될 때마다 if문 계속 추가해야 함 (OCP 위반) if (discountType.equals("AMOUNT")) { ..
1. 개요이번에 개발하는 프로젝트 요구사항에 실시간으로 기기의 정보를 받아와 관리자 화면에 보여줘야하는 요구사항이 있어 실시간성 기술이 필요한 기술을 사용하게 되었습니다. 제미나이와 토론하며 얻은 지식과 기술적 결정의 배경을 정리해, 비슷한 고민을 하는 분들과 나누고자 합니다.2. 기존에 웹 소켓을 사용했던 배경AWS 웹소켓은 수만 개의 커넥션을 직접 관리해 줍니다. 애플리케이션 서버는 연결 시 커넥션 정보만 저장하면, 이벤트 기반으로 쉽게 데이터를 전달할 수 있어요. 커넥션 리소스도 AWS가 처리하므로 서버 부담과 유지보수 비용이 모두 줄어듭니다. 이런 장점 덕분에 기존 애플리케이션은 소켓으로 실시간 조회를 제공했습니다. 하지만 IDC 환경에서는 상황이 다릅니다. AWS가 제공하던 기능을 직접 만들고..
1. 개요왜 이전에 스프링은 Runtime Exception을 상속받은 Unchecked Exception을 트랜잭션을 롤백하도록 구현하였을까요? 그건 바로 이전에 이야기했듯이 Unchecked Exception은 시스템적으로 처리를 할 수 없는 경우에 사용하기 때문입니다. 아래의 공식 문서 내용을 살펴봅시다.롤백 기본 규칙 (Default Rollback Policy)아래의 스프링의 공식문서를 살펴보면 Runtime Exception의 서브 클래스나 Error의 서브 클래스를 롤백을 지원하고 있다고 합니다. 이런 이유에 대해서는 자바의 Exception 철학 중 하나인 처리가 가능한 에러와 처리가 불가능한 에러를 분리하여 관리하기 때문입니다.자바 예외 철학과의 연결: 자바의 "처리가 가능한 에러(Che..
1, 왜 예외 코드가 엉망이 될까?실무에서 다음과 같은 코드를 본적이 있을 것입니다. 이런 방식의 코드는 Exception을 에러, 언체크 익셉션, 체크 익셉션의 개념을 충분하게 이해하지 못한채 활용하면서 컴파일러의 감시로부터 피하기 위해 민들어진 기술 부채입니다. Error는 메모리 부족이나 하드웨어 공간 부족 등의 시스템이 비정상적으로 돌아가면서 우리가 제어할 수 없는 상황에 사용해야 합니다. // 예외 블랙홀try { ...} catch (Exception e) {}// 출력만 하고 끝catch (Exception e) { e.printStackTrace();}// 무의미한 throws 전파public void method1() throws Exception { method2();}..
컨텍스트와 DI우리가 @Transactional을 붙이는 순간, 스프링 내부에서는 보이지 않는 두가지 역할을 합니다. 첫번째로는 트랜잭션 컨텍스트를 생성하는데 이 컨텍스트는 커넥션 획득 -> 트랜잭션 시작 -> 커밋 또는 롤백 -> 리소스 정리 등의 변하지 않는 행위를 하는 흐름이 저희의 코드를 감쌉니다. 이 컨텍스트가 실행되기 위해서는 PlatformTransactionManager을 구현한 구현체가 필요한데 이는 DI를 통해DataSourceTransactionManager 주입할 지 JpaTransactionManager를 주입할 지는 설정에 따라 달라지지만 비즈니스 로직은 그 차이를 알 수 없습니다. 컨텍스트는 반복되는 흐름을 추상화시킴으로써 반복되는 흐름을 재사용가능하도록 구현한 개념입니다. 이..
