heemang.dev heemang.dev

1. 낙관적 락(Optimistic Lock)이란?낙관적 락은 동시성 문제가 발생할 가능성이 낮다고 가정하고, 여러 트랜잭션이 동시에 데이터에 접근할 수 있도록 허용한다. 그러나 실제로 데이터를 변경할 때 충돌이 발생하면, 해당 트랜잭션은 롤백되고 예외를 발생시킨다.  JPA에서는 @Version 필드를 사용하여, 해당 엔티티가 변경될 때마다 버전 값이 증가한다. 트랜잭션이 종료되기 전에 다른 트랜잭션이 이 엔티티를 변경하여 버전이 증가한 것을 감지하면, OptimisticLockException이 발생하고 해당 트랜잭션은 롤백된다. 또한 데이터베이스의 물리적 락 기능을 사용하지 않고, 엔티티의 버전을 통해 동시성을 제어한다.2. OptimisticLockingFailureException 예외란?Opt..

1. READ UNCOMMITTED READ UNCOMMITTED는 커밋되지 않은 데이터에 접근이 가능하다.1-1. Dirty ReadREAD UNCOMMITTED 격리 수준에서는 Dirty Read가 발생한다. Dirty Read는 커밋되지 않은 데이터를 다른 트랜잭션에서 읽음으로써 발생하는 문제이다. 이는 아직 데이터베이스에 반영되지 않은 변경 사항을 읽기 때문에, 이후에 변경 작업을 수행한 트랜잭션이 ROLLBACK 될 경우 문제가 발생한다.트랜잭션 1이 공유 데이터 MIN을 KIM으로 UPDATE 한다.아직 데이터베이스에 커밋되지 않은 상태이다.이때, 트랜잭션 2는 트랜잭션 1이 커밋하지 않은 KIM 데이터를 읽는다.만약 트랜잭션 1이 중간에 문제가 발생하여 ROLLBACK 할 경우, 데이터는 다..

1. SELECT FOR UPDATESELECT * FROM Student WHERE id = 1 FOR UPDATE;SELECT FOR UPDATE를 실행하면 조회된 레코드에 대해 LOCK이 설정되어 해당 세션이 UPDATE 쿼리를 완료하고 COMMIT 또는 ROLLBACK 할 때까지 다른 세션에서 해당 레코드를 수정할 수 없다. 2. SELECT FOR UPDATE FlOW2-1. 테스트 환경도커를 사용하여 테스트 환경을 구성한다.MysQL 이미지 설치 : docker pull mysql:latestMySQL 컨테이너 실행 : docker run --name test-mysql-container -e MYSQL_ROOT_PASSWORD=1234 -d -p 3313:3306 mysql:latest My..

여러 개의 테스트를 동시에 실행하기 위해서는 각 테스트가 독립적으로 수행되어야 한다. 즉, 이전 테스트에서 수행한 내용이 다음 테스트에 영향을 미쳐서는 안 된다. 스프링을 사용한다면 @AfterEach 또는 @BeforeEach를 사용하여 각 테스트가 종료될 때마다 클렌징 처리가 가능하다. 이때, deleteAll(), deleteAllInBatch(), @Transactional 중에 하나를 사용하여 클렌징 처리가 가능하다. 셋 다 테스트에서 사용한 데이터를 지운다는 것은 동일하지만, 성능 상에 차이점이 존재한다.  각 방식의 차이점과 무엇을 사용해야 할지 알아보자. 1. 테스트 환경하나의 주문(Order)에는 여러 개의 상품이 포함될 수 있다.하나의 상품(Product)은 여러 개의 주문에 포함될 수..

Mockito와 BDDMockito 둘 다 Java 기반의 테스트 프레임워크로, 모킹(mocking)을 지원한다. 이 둘은 기능상에 차이점은 없으나, 모킹하는 스타일 방식이 차이가 있다.1. Mockito를 통해 Mock 객체 생성하는 방법@Mock 애너테이션을 통해 Mock 객체를 생성하고, @InjectMocks 애너테이션을 통해 Mock 객체를 주입할 수 있다. 예를 들어, MailService 객체를 생성하기 위해서 MailSendClient와 MailSendHistoryRepository가 필요하다. 이를 위해 @Mock 애너테이션을 사용하여 MailSendClient와 MailSendHistoryRepository 클래스의 Mock 객체를 생성하고, @InjectMocks 애너테이션을 통해 이..

1. 사건 발달스프링 시큐리티 환경에서 MVC를 테스트하기 위해서는 요청 헤더에 CSRF 토큰이 필요하다. 따라서 아래 코드와 같이 perform() 시에 요청 헤더에 스프링 시큐리티가 생성한 CSRF 토큰을 포함할 수 있다.근데 테스트 코드를 작성할 때마다 CSRF 토큰을 일일이 추가하는 것보단, 테스트 실행 전에 자동으로 추가할 수 있지 않을까? @WithMockUser@WebMvcTest(controllers = SectionController.class)class SectionControllerTest { @Test @DisplayName("신규 회고카드를 등록한다.") void createSection() throws Exception { //given ..