25G.story

ThreadLocal 쓰래드 로컬을 알고있어야 하는 이유중 하나는 동시성 문제이다. 동시성 문제 동시성 문제? 첫호출작업이 끝나기도 전에 동시에 다발적으로 호출하게되면 로그가 분리되지않고 떡져서 출력된다. 즉 어떠한 작업을 수행하는 스레드의 트랜젝션이 보장이 되지 않는것이다. 이런 동시성 문제는 여러 쓰레드가 같은 인스턴스 필드에 접근해야 하기 때문에 트래픽이 적은 상황에서는 확율상 잘 나타나지않고 트래픽이 점점 많아질수록 자주 발생해야한다. 특히 스프링 빈처럼 싱글톤 객체의 필드를 변경하며 사용할때 이러한 동시성 문제를 조심해야한다 java에서 지역변수에는 동시성문제가 발생하지 않다. 왜냐하면 스레드마다 각각 다른 메모리 영역이 할당한다. 동시성문제가 발생하는곳은 같은 인스턴스필드 (싱글톤 static..

es에 복잡한 쿼리를 날리기 위해서 보통 QueryBuilders를 활용해서 간편하게 문자열을 만들 수 있습니다. 이때 페이징 처리를 하기 위해서는 조회하고자 하는 query를 만든 다음다음과 같이 해결했습니다. private final SearchOperations searchOperations; NativeSearchQuery result = new NativeSearchQueryBuilder() .withFields(fields) .withPageable(PageRequest.of(Math.toIntExact(pageable.getOffset()), pageable.getPageSize())) .withSort(Sort.by("id").descending()) //desc or asc .withQu..

Jpa를 사용하다 보면 update를 할 때 dto에 @Valid를 활용해서 밸리데이션 체크를 하기도 애매하고 api서버로써 클라이언트와 통신을 하다 보면 리 엑트에서 undifind로 필드조차도 보내지지 않거나 null값이 들어가는 것을 서버에서 체크해줄 필요가 있다. 그런데 문제는 너무 귀찮다는 것입니다. 필드마다 null체크를 해서 setter로 더티 체킹을 유도하는 작업이 update시에 굉장히 귀찮고 피곤했습니다. 그래서 다음과 같은 util class를 만들어 봤습니다./** * update시에 null과 field가 없는 것을 체크해서 dto에 데이터가 있는부분만 entity 객체에 입혀주는 util class */public class DtoFieldEmptyChecker { publ..

지연로딩(Lazy)? 즉시로딩(Eager)? entity의 연관관계가 매핑된 상황을 가정하고 지연로딩과 즉시로딩을 간단하게 설명하면 다음과같습니다. 지연로딩 : 연관된 엔티티를 프록시로 조회한다. 프록시를 실제사용할때 (예를들어 getter호출) 초기화하면서 데이터 베이스를 조회합니다. 즉시로딩 : 연관된 엔티티를 즉시 조회합니다. 하이버네이트는 가능하면 SQL JOIN을 통해서 한번에 조회합니다. 그렇다면 어느것이 더 좋은것을까? 처음부터 연관된 엔티티를 모두 영속성 컨텍스트에 올려두는것은 현실적이지 않습니다. 산에가는데 꼭 모든 장비가 있어야하는것은 아닙니다. 때로는 물통한통만 있어도 되는것과 같습니다. 그럼 지연로딩이라고 무조건 좋은것일까? 한다면 최적화 관점에서보면 꼭 좋지만은 않습니다. 대부분의..

동시성 문제? 동시성 문제란 여러 스레드가 동시에 같은 인스턴스의 필드 값을 변경하면서 발생하는 문제를 동시성 문제라 한다. 이런 동시성 문제는 여러 쓰레드가 같은 인스턴스의 필드에 접근해야 하기 때문에 트래픽이 적은 상황에서는 확률상 잘 나타나지 않고, 트래픽이 점점 많아질 수 록 자주 발생한다. 특히 스프링 빈처럼 싱글톤 객체의 필드를 변경하며 사용할 때 이러한 동시성 문제를 조심해야 한다. 예를 들어 1명의 유저가 2개의 카드만 생성할 수 있다고 시스템에서 정의를 해놓고 테스트도 다 해봤을 때 2개 이상 절대 들어갈 일이 없을 것이라 생각했다. 그리고 서비스 첫날 서비스가 대박 나서 트래픽이 막막 몰려왔고 서버에서 스레드가 꼬여서 어떠한 유저는 카드를 2개를 초과해서 받는 일이 생길 수도 있다. 그..

Maven 과 Gradle manen xml 기반 프로젝트 의존성 관리 도구 해당 라이브러리를 사용하기 위한 다른라이브러리까지 저장소에서 다운받아 준다. 전체적인 라이프사이클 관리 도구 Maven Lifecycle Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계 Validate : 프로젝트가 올바른지 확인학고 필요한 모든 정보를 사용할 수 있는 지 확인하는 단계 Compile : 프로젝트의 소스코드를 컴파일하는 단계 Test : 유닛(단위) 테스트를 수행하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능) Package : 실제 컴파일된 소스 코드와 리소스들을 jar등의 배포를 위한 패키지로 만드는 단계 Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는..

@Transient db에 컬럼이 만들어지지 않게 하고 싶을 때 사용하는 어노테이션입니다. 뷰에 렌더링할때 칼럼에 필요 없거나 추가하면 문제가 생기는 데이터지만 값을 뷰로 들고 가야 하는 경우가 있다. 이럴 때 javax.persistece가 들고 있는 Transient어노테이션을 사용하면 DB에 컬럼을 만들지 않고도 변수를 담아서 데이터를 뷰로 들고 갈 수 있습니다.

지금 현재 하고 있는 프로젝트에서 페이징 처리를 해 보려고 합니다. 위 어노테이션을 사용해서 spring에서 페이징처리를 할 수 있습니다. 다음과 같이 페이징 할 설정들을 어노테이션에 달아주고 해당 객체를 Service를 하는 곳으로 던져 준다. 이때 List가 아닌 Page타입으로! Service단에서 받아주고 repository를 사용해서 호출하는 메서드도 위 상황과 코드에 맞게 수정해 준다. 이렇게만 설정해 주면 내부적으로 Spring이 알아서 페이징 처리를 해 주는데 postman으로 테스트를 해보면 다음과 같은 데이터가 넘어온다. data내부에 content안에 있다. (데이터를 뿌려줄때 이 구조로 돼 있지 않으면 데이터가 view에서 보일 수 없다.) 그리고 데이터를 보다 보면 pageable..

QLRM라이브러리 사용해서 DTO를 매핑해 보겠습니다. QLRM라이브러리 의존성 org.qlrm qlrm 2.1.1 QLRM라이브러리란?? qlrm은 DB에서 Result 된 결과를 자바 클래스에 메핑 해주는 라이브러리. QLRM를 사용하는 이유 다음과같은 쿼리는 모델의 형태로 리턴 받을 수 없고 DTO로 받아내야 하는 쿼리다. 이처럼 DTO로 받아 내야 하는 쿼리라면 JPARepository를 상속받은 인터페이스로 native쿼리를 짜서 날릴 수 없다. 왜냐하면 상속받은 클래스 타입의 모델만 리턴을 해주기 때문. 그렇기 때문에 DTO로 DB에서 결과를 받아야하면 JPARepository를 사용할 수 없다. 기능예시 그래서 @Service단에서 직접 쿼리를 짜서 던져야한다. 주석이 중요한 내용이고 코드는..

현재 이지업에 강의를 보면서 진행하는 프로젝트에서 사용자의 구동 적보를 관리하는 기능이 있다. 이기능은 까다로워서 프로그램을 설계해서 짜게되면 프로그램도 지저분해지고 엄청 복잡해 진다. 그래서 이런 복잡한 기능은 쿼리를 잘 짠다면 엄청깔끔하게 프로그램을 작성할 수 있게된다. 쿼리를 짜는 실력이 늘기위해선 해당 포스팅에서 보여주는것과 같이 생각을하면서 점차점차 목표하는 쿼리를 만들기위해서 생각하고 연습하고 노력해야한다. 다음과 같은데 위 기능이 구현하기 까다로운 이유는 user정보도 있고 구독여부 정보와 사용자와 중복 여부까지 체크를 해야 한다. 이렇게 하기 위해서 쿼리를 짜야한다. 조인을 해야하는데 조인은 다음과 같이 데이터를 검색해 준다. 2번이 구독하고 있는 user들을 검색하는 쿼리를 짜고 이제 구..