save와 saveAll의 차이save의 내부 로직ave를 살펴보면, 하나의 트랜잭션에서 관리가 되고 있으며,주어진 entity가 새 entity의 경우, persist를 통해 DB에 저장하며기존에 존재하는 entity의 경우, merge를 통해 변경된 점을 DB에 병합한다.saveAll의 내부로직saveAll을 살펴보면, 이 메서드 역시 하나의 트랜잭션에서 관리된다.내부적으로는 for문을 통해 save를 반복 호출하게된다.그렇다면 save와의 차이점은 어떤것일까?가장 큰 차이는 트랜잭션 관리이다. saveAll에서는 트랜잭션이 메서드 레벨에 위치하여작업 수행동안 동일한 트랜잭션 내에서 처리된다.따라서 for문을 통해 save를 직접 반복 호출하는 것보다 더 효율적일 수 있다.즉, saveAll을 사용할..

단일 서버에서 세션을 관리한다면 아무런 문제가 없겠지만, 보통 스케일 아웃 등을 통해 분산된 서버 환경에서 세션을 관리할 때 세션 불일치 문제가 발생할 수 있다.이러한 문제를 해결하기 위해 Session Clustering, Sticky Session, Redis Session Clustering 등이 존재한다.Sticky Session세션을 사용해 트래픽을 분산하는 기능으로, 특정 세션의 요청을 최초 처리한 서버로만 전송하는 것을 의미한다.예를 들어 회원 1이 서버A에서 세션을 생성한다면, 이후 회원1이 보내는 모든 요청은 서버A로만 전송하게 된다.이러한 Sticky Session은 아래와 같은 단점이 존재한다.동일한 세션은 동일한 서버로만 전송하기 때문에 특정 서버에 요청이 몰려 과부하가 발생할 수 ..

참조자료https://yozm.wishket.com/magazine/detail/2488/https://faq.portone.io/3df572fb-7ab6-4933-a383-3741efb0aa4dhttps://zhfvkq.tistory.com/100CI (88Byte의 Hash처리된 값)온라인에서 개인식별을 위해 주민번호에 기반하여 생성된 온라인 주민번호로, 필요한 경우 서로 연계가 가능하다.공인인증서나 휴대폰 인증 등을 통해 최초 발급 후에는 해당 CI를 이용해 본인임을 증명하게 된다.주민번호를 단방향 암호화하여 생성된다.DI (66byte)사이트별 개인 고유 식별키주민번호와 각 웹사이트의 식별번호를 가지고 생성하는 방식특정 유저가 가입한 이력이 있는지 등을 확인하기 위한 정보중복 가입을 방지하기 위해..

출처 : 인프런 Practical Testing을 수강하며 정리하였습니다. MockMvc Mock(가짜) 객체를 사용해 스프링 MVC동작을 재현할 수 있는 test framework @Transactional(readOnly = true)와 @Transactional을 분리해야한다! 위처럼 하게되면, JPA에서 이점이 발생하게 된다. JPA에서는 스냅샷을 저장해서 트랜잭션이 commit하는 시점에 변경감지를 한다. readOnly = true를 하게 되면, create, update, delete작업이 동작을 하지 않아서 스냅샷 저장 및 변경감지를 하지 않아도 되는 이점이 발생한다. 즉, 성능향상의 효과가 발생한다! CQRS - Command(create, update, delete)와 Query(Rea..

deleteAll vs deleteAllInBatch deleteAll() : SimpleJpaRepository()에 오버라이딩되어 있으며, MyBatis, JdbcTemplate 등 기술에 상관없이 사용가능하다. 또, deleteAll()이 실행되면, findAll()의 결과로 얻은 리스트를 순회하며, 데이터를 한개씩 삭제함. 즉, N개의 데이터가 존재하면 N개릐 DELETE쿼리가 실행된다. -> 테스트 실행시간이 오래 걸림. deleteAllInBatch() : 테이블에 있는 데이터를 전부 지우는 DELETE쿼리가 실행된다. 즉, 데이터 크기와 관계없이 한번의 쿼리로 clear가 가능함. package org.springframework.data.jpa.repository.support; @Repo..

@NoArgsConstructor(access = AccessLevel.PROTECTED) 기본 생성자를 추가할때, AccessLevel을 PRIVATE이 아닌 PROTECTED를 하는 이유는? @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) // 기본생성자를 생성하되, 접근수준을 protected로 하자! @Entity public class Product extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String productNumber; } @NoArgsConstructor(access = AccessLeve..