트랜잭션이란?

데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위를 뜻한다.

데이터베이스의 상태를 변화시킨다는 것은 무얼 의미하는 것일까?

간단하게 말해서 아래의 질의어(SQL)를 이용하여 데이터베이스를 접근 하는 것을 의미한다.

• SELECT
• INSERT
• DELETE
• UPDATE

착각하지 말아야 할 것은, 작업의 단위는 질의어 한문장이 아니라는 점이다.

작업단위는 많은 질의어 명령문들을 사람이 정하는 기준에 따라 정하는 것을 의미한다.

게시판을 예로 들어보자.

게시판 사용자는 게시글을 작성하고, 올리기 버튼을 누른다. 그 후에 다시 게시판에 돌아왔을때,

게시판은 자신의 글이 포함된 업데이트된 게시판을 보게 된다.

이러한 상황을 데이터베이스 작업으로 옮기면, 사용자가 올리기 버튼을 눌렀을 시, Insert 문을 사용하여

사용자가 입력한 게시글의 데이터를 옮긴다. 그 후에, 게시판을 구성할 데이터를 다시 Select 하여 최신 정보로

유지한다. 여기서 작업의 단위는 insert문과 select문 둘다 를 합친것이다. 이러한 작업단위를 하나의 트랜잭션이라 한다.

관리자나 개발자가 하나의 트랜잭션 설계를 잘하는 것이 데이터를 다루는 것에 많은 이점이 있다.

트랜잭션의 특징

트랜잭션의 특징은 크게 4가지로 구분된다.

• 원자성 (Atomicity)
• 일관성 (Consistency)
• 독립성 (Isolation)
• 지속성 (Durability)

첫번째로, 원자성은 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다.  트랜잭션은 사람이 설계한

논리적인 작업 단위로서, 일처리는 작업단위 별로 이루어 져야 사람이 다루는데 무리가 없다.

만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을시 원인을 찾기가 매우 힘들어질것이다.

첫번째로, 원자성은 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다.  트랜잭션은 사람이 설계한

논리적인 작업 단위로서, 일처리는 작업단위 별로 이루어 져야 사람이 다루는데 무리가 없다.

만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을시 원인을 찾기가 매우 힘들어질것이다.

두번째로, 일관성은 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것이다.

트랜잭션이 진행되는 동안에 데이터베이스가 변경 되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는것이 아니라,

처음에 트랜잭션을 진행 하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자는 일관성 있는 데이터를 볼 수 있는 것이다.

세번째로, 독립성은 둘 이상의 트랜잭션이 동시에 실행되고 있을 경우 어떤 하나의 트랜잭션이라도, 다른 트랜잭션의 연산에 끼어들 수 없다는 점을 가리킨다.

하나의 특정 트랜잭션이 완료될때까지, 다른 트랜잭션이 특정 트랜잭션의 결과를 참조할 수 없다.

네번째로, 지속성은 트랜잭션이 성공적으로 완료됬을 경우, 결과는 영구적으로 반영되어야 한다는 점이다.

트랜잭션의 Commit, Rollback 연산

Commit이란 하나의 트랜잭션이 성공적으로 끝났고, 데이터베이스가 일관성있는 상태에 있을 때, 하나의 트랜잭션이 끝났다라는 것을

알려주기위해 사용하는 연산이다. 이 연산을 사용하면 수행했던 트랜잭션이 로그에 저장되며, 후에 Rollback 연산을 수행했었던 트랜잭션단위로 하는것을 도와준다.

Rollback이란 하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션의 원자성이 깨진경우, 트랜잭션을 처음부터 다시 시작하거나, 트랜잭션의 부분적으로만 연산된 결과를 다시 취소시킨다.

후에 사용자가 트랜잭션 처리된 단위대로 Rollback을 진행할 수도 있다.

트랜잭션(Transaction)은 데이터베이스 시스템에서 하나의 논리적 기능을 나타내는 것으로, 여러 개의 연산을 하나로 묶어서 처리하는 단위입니다.

예를 들어, 계좌 이체 기능은 여러 개의 쿼리(예: 송금하는 계좌에서 잔액 감소, 수취하는 계좌에서 잔액 증가)로 구성될 수 있지만, 하나의 트랜잭션으로 묶어서 처리함으로써 정합성(Consistency)을 보장합니다.

트랜잭션은 세 가지 특성(ACID)을 가져야 합니다:

1. Atomicity(원자성): 트랜잭션은 전체가 완료되어야만 완료된 것으로 간주되고, 트랜잭션 중간에 실패한 경우에는 전체가 취소됩니다.
2. Consistency(정합성): 트랜잭션이 완료된 후에는 데이터베이스의 정합성을 유지하는 것이 보장됩니다.
3. Isolation(고립성): 트랜잭션은 다른 트랜잭션과 독립적으로 처리되어야 하며, 한 트랜잭션이 데이터베이스를 수정하는 것이 완료되어야만 다른 트랜잭션이 이에 영향을 받지 않습니다.
4. Durability(영구성): 트랜잭션이 완료된 후에는 그 결과가 영구적으로 저장되어야 합니다.

이 ACID 특성을 가지면서 트랜잭션이 처리되는 것으로써, 데이터베이스 시스템에서 데이터 손실이나 오류 발생을 방지할 수 있습니다.

예시: 계좌 이체 트랜잭션

• 트랜잭션이 시작되면, 고객의 계좌에서 일정 금액이 이체되는 것과 동시에 다른 고객의 계좌로 같은 금액이 입금되는 것이 완료되어야 합니다.
• 만약 첫 번째 과정에서 오류가 발생하여 고객의 계좌에서 금액이 이체되지 않았다면, 트랜잭션은 취소되어야 합니다.

예시: 온라인 쇼핑 트랜잭션

• 트랜잭션이 시작되면, 고객이 쇼핑 카트에 물건을 담고 결제를 진행합니다.
• 결제가 완료되면, 고객의 결제 정보와 주문 내역이 데이터베이스에 저장되고, 상품이 배송될 준비가 됩니다.
• 만약 결제 과정에서 오류가 발생하여 결제가 완료되지 않았다면, 트랜잭션은 취소되어야 합니다.

@SpringBootTest와 @WebMvcTest의 차이점을 설명해 주세요.

1. @SpringBootTest

• 이 어노테이션은 통합 테스트를 수행할 때 사용된다.
• @SpringBootTest 어노테이션을 사용하면 전체 Spring ApplicationContext를 로드한다.
• 이는 모든 Bean들을 초기화하고 모든 구성을 로드한다는 것을 의미한다.
• 따라서 애플리케이션의 전체 동작을 테스트하려는 경우에 사용된다.
• 하지만 이는 상당한 시간과 자원을 필요로 한다.

@SpringBootTest
public class ApplicationTest {

    @Autowired
    private MyService myService;

    @Test
    public void contextLoads() {
        // 테스트 코드...
    }
}

2. @WebMvcTest

• @WebMvcTest 어노테이션은 웹 계층만을 테스트하는 데 사용된다.
• Spring MVC 인프라를 설정하고 웹 관련 빈들만 로드한다.
• 컨트롤러, 컨트롤러 어드바이스, 필터, 인터셉터 등과 같은 웹 관련 구성만 로드한다는 것을 의미한다.
• 이 어노테이션은 MockMvc 인스턴스를 자동으로 제공하여, HTTP 요청을 디스패처 서블릿에 보내고 그 결과를 검증할 수 있다.
• **@WebMvcTest**는 빠른 피드백을 제공하며, 컨트롤러 단위 테스트를 하는 데 유용하다.

@WebMvcTest(MyController.class)
public class MyControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void testMyController() throws Exception {
        this.mockMvc.perform(get("/"))
            .andExpect(status().isOk())
            .andExpect(content().string("Hello World"));
    }
}

따라서, @SpringBootTest와 @WebMvcTest의 주요 차이점은 테스트의 범위와 로드하는 ApplicationContext의 범위에 있다. @SpringBootTest는 전체 ApplicationContext를 로드하고, @WebMvcTest는 웹 계층에 관련된 부분만 로드한다.

SpringBoot에서 JUnit을 사용하여 테스트 코드를 작성할 때

@SpringBootTest 어노테이션을 자주 쓰게 되는데, 상황에 따라서는 @WebMvcTest를 쓰는게 좋을 때도 있다.

@SpringBootTest와 @WebMvcTest는 둘 다 Spring Boot 테스트를 위한 어노테이션입니다. 하지만 두 어노테이션은 사용되는 컨텍스트와 테스트의 범위에 따라 크게 다릅니다.

Junit이란 자바 개발자의 93%가 사용하는 단위 테스트 프레임워크이며 Java8 이상부터 지원한다.

JUnit5의 경우 2017년 10월에 공개

스프링부트의 경우 2.2버전부터 기본적으로 제공된다.

@SpringBootTest + @AutoConfigureMockMvc

• 프로젝트 내부에 있는 스프링 빈을 모두 등록하여 테스트에 필요한 의존성을 추가한다.
• 실제 운영 환경에서 사용될 클래스들을 통합하여 테스트한다.
• 단위 테스트와 같이 기능 검증을 위한 것이 아니라, Spring Framework에서 전체적으로 Flow가 제대로 동작하는지 검증하기 위해 사용한다.

장점

• 애플리케이션의 설정, 모든 Bean을 모두 로드하기 때문에 운영환경과 가장 유사한 테스트가 가능하다.

단점

• 테스트 단위가 크기에 디버깅이 까다로움
• 어플리케이션의 설정, 모든 Bean을 로드하기 때문에 시간이 오래 걸림

@SpringBoottest
@AutoConfugurMockMvc
class SenderControllerTest {

	@Autowited
	private MockMvc mockMvc;

	@Autowited
	private ObjectMapper objectMapper;

	@MockBean
	private SenderService senderService;
}

@WebMvcTest

• MVC를 위한 테스트, 컨드롤러가 예상대로 작동되는지 테스트하기 위해 사용된다.
• Web Layer만 로드하며, @WebMvcTest어노테이션을 사용시 아래의 항목들만 스캔하도록 제한하여 보다 빠르고 가벼운 테스트가 가능하다.

장점

• WebApllication과 관련된 Bean들만 등록하기 때문에 @SpringBootTest보다 빠르다.
• 통합테스트를 진행하기 어려운 테스트를 개별적으로 진행 가능

단점

• Mock을 기반으로 테스트하기 때문에, 실제 환경에서는 예상 밖의 동작오류가 발생할 수 있다.(참고: 위의 @SpringBootTest에는 @ExtendWith(SpringExtension.class)가 포함되어있음)
• @WebMvcTest()의 프로퍼티로 테스트를 원하는 컨트롤러 클래스를 넣어준다.

@ExtendWith(SpringExtension.class)
@WebMvcTest(SenderController.class)
class SenderControllerTest {

	@Autowited
	private MockMvc mockMvc;

	@Autowited
	private ObjectMapper objectMapper;

	@MockBean
	private SenderService senderService;

	@MockBean
	private AraClient araClient;
}

어제도 깜빡하고.. TIL을 쓰지 않았습니다 ㅠㅠ

어제 공부할 때 소프트웨어 아키텍쳐에 대해 공부했는데, 이부분에 대해 짧게 정리했습니다.

To do

• [x] 아침운동하기
• [x] 코테5문제풀기 1레벨 시작~ 2레벨도 풀어보자~
• [x] 자바 3페이지 읽기
• [x] cs책 읽고 정리하기 9, 10, 11, 12, 13
• [x] 이력서 수정하기
• [x] 이력서 과제
• [x] 목터뷰 암기 최소 2개 이상!!

외부일정

• [x] 멘토링

1. 계층형 아키텍처: 이 아키텍처는 시스템을 몇 가지 계층으로 나눕니다. 각 계층은 특정 기능을 수행하며, 특정 계층은 그 아래의 계층에만 의존합니다. 예를 들어, 전형적인 3계층 아키텍처는 프레젠테이션 계층(사용자 인터페이스), 비즈니스 로직 계층, 그리고 데이터 액세스 계층으로 구성됩니다.
2. 클라이언트-서버 아키텍처: 이 아키텍처는 클라이언트(요청을 하는 시스템)와 서버(요청을 처리하고 응답하는 시스템)로 구성됩니다. 웹 브라우저(클라이언트)와 웹 서버의 상호작용이 이 아키텍처의 한 예시입니다.
3. 마이크로서비스 아키텍처: 이 아키텍처는 시스템을 작고 독립적인 서비스들로 분리합니다. 각 마이크로서비스는 특정 비즈니스 기능을 수행하며, 서로 다른 서비스와 네트워크를 통해 통신합니다. 예를 들어, 전자 상거래 시스템에서는 상품 카탈로그, 장바구니, 결제, 배송 추적 등 각각의 기능이 별도의 마이크로서비스로 구현될 수 있습니다.
4. 이벤트 주도 아키텍처: 이 아키텍처는 시스템의 구성요소들이 이벤트를 생성하고 수신함으로써 상호작용합니다. 예를 들어, 사용자가 웹사이트에서 주문을 하면 "주문 생성" 이벤트가 발생하고, 이를 처리하는 다른 컴포넌트(예: 재고 관리 시스템)가 이 이벤트를 수신하여 상황에 맞게 반응합니다.