HTTP의 Stateless HTTP 프로토콜은 기본적으로 요청 ↔ 응답을 진행한 후 이전 통신에 대한 상태를 저장하지 않는 Stateless한 구조를 가지고 있다 HTTP가 Stateless함에 따라 다음과 같은 이점이 존재한다 상태를 유지하기 위한 오버헤드가 줄어든다 상태를 유지하지 않기 때문에 확장성(Scale Out)이 높다 하지만 어느 특정 상황에서는 Client측의 여러 정보들을 Server측에서 기억해야 할 필요가 있어졌고 Client-Server간의 상태를 Stateful하게 유지해야 할 필요성이 높아졌다 특정 사용자 접속 제한 사용자에 따른 추천 시스템 ... 쿠키 쿠키는 HTTP의 Stateless함을 보완하기 위해서 Client측에 일시적/영구적으로 저장되는 정보이다 특징 웹 브라우저..
ArgumentResolver Spring Framework에서 ArgumentResolver는 굉장히 중요한 핵심 개념이다 사용자의 Request가 들어오는 순간 처리 메커니즘을 간단하게 알아보자 1. 사용자의 Request가 DispatcherServlet으로 들어온다 2. DispatcherServlet은 들어온 Request를 처리할 수 있는 Handler를 조회 3. 조회한 Handler를 컨트롤할 수 있는 HandlerAdapter 조회 4. HandlerAdapter가 본인이 컨트롤하는 Handler를 invoke 4단계 :: Handler를 invoke하는 프로세스에서 ArgumentResolver가 활용된다 이 말이 무슨 의미인지 정확하게 이해가 되지 않을 수 있으니 상세하게 풀어서 살펴..
비영속? 준영속?Entity의 상태에는 4가지가 존재한다비영속 = 영속성 컨텍스트와 전혀 관련이 없는 상태영속 = 영속성 컨텍스트가 관리하고 있는 상태준영속 = 영속성 컨텍스트의 관리를 더이상 받지 않는 상태삭제 = 아예 삭제가 된 상태 여기서 준영속 상태를 영속성 컨텍스트의 관리를 더이상 받지 않는 상태라고 설명하였다그런데 이를 다른 측면에서 바라보면 다음과 같이 설명할 수 있다영속성 컨텍스트의 관리를 받기 위해서는 식별자 @Id가 반드시 필요하다따라서 영속성 컨텍스트의 관리를 더이상 받지 않는다는 것은 다르게 말하면 식별자는 존재하는 상태라고 볼 수 있다 이 시점에 다음 엔티티를 한번 살펴보자@Getter@Setter@NoArgsConstructor@Entity@Tab..
Transaction 전파 트랜잭션은 시작 지점 & 종료 지점이 명확하게 존재한다 시작 지점은 하나이지만 종료 지점은 둘로 분류할 수 있다 Commit Rollback 특정 로직을 진행하다가 추가적인 트랜잭션이 진입하는 경우를 생각해보자 이 때 기존에 존재하는 트랜잭션에 대해서 추가적으로 진행되는 트랜잭션의 행동은 트랜잭션 전파 속성에 의해 결정된다 물리 트랜잭션 vs 논리 트랜잭션 단일 트랜잭션인 상황에서는 사실 트랜잭션의 개념 자체를 물리/논리로 나눌 필요가 없다 논리 트랜잭션 그 자체가 물리 트랜잭션이기 때문에 하지만 여러 트랜잭션이 중첩된 상황에서는 물리/논리라는 개념으로 분리될 필요가 있다 이러한 상황에서 물리 트랜잭션 / 논리 트랜잭션간에는 다음과 같은 규칙이 존재한다 1. 모든 논리 트랜잭션..
Transaction - Connection간의 관계 트랜잭션을 열고 유지하기 위해서 트랜잭션의 시작 ~ 끝까지 다음과 같은 이유로 DB Connection을 동기화해야 한다 트랜잭션 내부의 여러 연산 로직은 원자성 (All or Nothing)을 보장해야 한다 이 과정에서 모든 연산은 동일한 DB Connection을 사용해야 한다 만약 중간에 Connection이 변경되면 연산 간의 데이터 일관성을 보장할 수 없게 된다 파라미터를 통한 Connection 동기화 방법 fun logic() { val connection: Connection = ... componentA.execute(connection, ...) componentB.execute(connection, ...) componentC.ex..
트랜잭션? - 여러 작업에 대해서 하나의 논리적인 단위로 취급해서 원자성을 보장 - 더이상 쪼갤 수 없는 논리적 최소 작업 단위 논리적 작업 단위에 대한 All or Nothing 보장 // 사용자 가입 로직 fun logic() { memberRepository.save(...) // 사용자 정보 저장 bucketRepository.save(...) // 사용자 전용 버킷 저장 ... } 사용자 가입을 진행하기 위한 위의 로직은 하나의 트랜잭션으로 묶여 있고 따라서 내부 로직들은 All or Nothing이 보장된다고 하자 그런데 중간에 어떠한 이유로 인해 특정 로직이 실패하게 된다면 트랜잭션 단위의 모든 로직은 Rollback되어야 한다 순수 JDBC vs ORM(JPA) 트랜잭션 처리 방식 자바를 ..
HttpServletRequest 서버에 요청을 보낼때 QueryString에 요청 정보들을 보내면 서버에서는 HttpServletRequest의 getParameter를 통해서 값을 얻을 수 있다 HttpServletRequest getParameter의 리턴 타입은 String @RestController public class BasicRequestController { @GetMapping("/basic") public String basicRequest(HttpServletRequest request) { String tech = request.getParameter("tech"); int level = Integer.parseInt(request.getParameter("level")); re..