Intellij가 알아서 고쳐주던 아래 에러에 대해서 좀 더 깊숙히 알고자 정리하는 글입니다. Variable used in lambda expression should be final or effectively final 에러에 대한 결론부터 람다 실행시에 실행되던 메소드의 스택 영역에 저장되는 외부 변수들에 대해서는 참조만 가능하고 값 변경은 불가 → final or effectively final 변수만 사용 가능한 이유 외부 Reference type 변수에 대한 변경은 힙 메모리 데이터를 변경하는것이기 때문에 가능 (변수 초기화 같은 스택 참조값 변경은 동일하게 불가) 위 현상들의 이유는 람다가 실행될때 람다 캡처링이 일어나면서 발생하는 현상 람다 캡처링이 일어나게되면 람다의 새로운 스택을 생성..
JPA를 사용하다 보면 바로 N+1의 문제에 마주치고 바로 Fetch Join을 접하게 됩니다. 처음 Fetch Join을 접했을 때 왜 일반 Join으로 해결하면 안되는지에 대해 명확히 정리가 안된 채로 Fetch Join을 사용했습니다. 어떤 문제 때문에 일반 join으로 N+1을 해결하지 못하는지를 시작으로 해서 Fetch Join, Join의 차이점을 정리해보겠습니다. 사용한 예제는 github에 업로드해두었으니 참고 바랍니다. https://github.com/cobiyu/join-fetchjoin-compare cobiyu/join-fetchjoin-compare Contribute to cobiyu/join-fetchjoin-compare development by creating an ac..
본 포스팅은 아래 키워드를 검색하는 분들에게 참고가 될 만한 글입니다. Methods annotated with '@Transactional' must be overridable jpa transactional private jpa transaction same class same class transaction not working call transaction method from other transaction 예제 코드는 아래 github에 작성되어 있습니다. https://github.com/cobiyu/transactional_proxy cobiyu/transactional_proxy Contribute to cobiyu/transactional_proxy development by creat..
예제 코드 https://github.com/cobiyu/MockitoSample Test Double이 왜 필요한 지부터 시작하는 기본적인 테스트 코드부터 한 단계씩 발전시켜나가며 Mockito의 어노테이션들의 정확한 쓰임새에 대해 살펴보겠습니다. github에 케이스별로 파일별로 구분 지어 놨으니 참고 부탁드립니다. Test Double (Mockito) 스프링과 Junit을 이용해서 테스트 코드를 작성하다 보면 테스트 환경(database, api)을 구현하는 코드까지 작성해야 하고 실제 테스트할 코드보다 환경을 구현하는 코드가 훨씬 더 복잡해지게 됩니다. 이런 문제 영역을 해결하기 위해서 테스트 더블 이라는 것이 나왔고 Java진영에서는 대표적으로 Mockito가 있습니다. Mockito의 어노테..
본 예시는 제 github에 springboot의 h2를 사용한 형태로 레파지토리를 구성해놨습니다. (https://github.com/cobiyu/querydsl) 처음 JPA(Hibernate)를 도입하는 과정 중 제일 난감한 부분은 OneToOne이라고 생각합니다. 아래 테이블 구조를 참고로 문제 영역에 대한 예시를 설정해 보겠습니다. member는 1개의 phone만 소유 가능하며 소유하지 않을 수도 있음 member는 favorite이라는 N개의 찜한 상품을 소유할 수 있음 member는 favortie의 목록을 기반으로 order 테이블에 주문서를 생성 할 수 있음 "찜한 상품" 목록을 이용한 주문서 만들기 (https://github.com/cobiyu/querydsl 의 before 브랜치..
@NoargsConstructor(AccessLevel.PROTECTED) 와 @Builder를 함께 사용할때 주의할 점에 대해서 서술합니다. "왜" 안되는지와 "왜" 이렇게 해결 할 수 있는지에 대해 집중하여 서술합니다. 1. 왜 NoargsConstructor(AccessLevel.PROTECTED)를 사용하는가? @NoargsConstructor(AccessLevel.PROTECTED) Entity나 DTO를 사용할때 @NoargsConstructor(AccessLevel.PROTECTED) 어노테이션을 많이 사용하는 편입니다. 기본 생성자의 접근 제어를 PROTECTED로 설정해놓게 되면 무분별한 객체 생성에 대해 한번 더 체크할 수 있는 수단이 되기 때문입니다. 예를 들어 User라는 Class..
예제는 모두 Github(https://github.com/cobiyu/CompletableFuture)에 있으니 참고 바랍니다. 문제가 되는 상황 Micro Service Architecture를 구성하게되면 여러 API로 나뉘어 지는 만큼 API끼리 서로를 호출하는 상황이 많이 발생하게 됩니다. 그리고 자연 스럽게 아래 예제와 같은 문제가 발생하게 됩니다. public class SyncTest { Logger logger = LoggerFactory.getLogger(this.getClass()); public Integer goodsPriceApi() throws InterruptedException { logger.info("goodsPriceApi start"); TimeUnit.SECONDS..
flush 영속성 컨텍스트의 변경 내용을 DB에 반영하는 이벤트 JPQL JPQL : Jpa의 Entity 객체들을 이용해서 Query할수있는 객체 지향 쿼리 예제 /** * User.java */ @Entity @Getter @Setter @NoArgsConstructor public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; public User(String name) { this.name = name; } } 실행하려는 로직은 아래와 같습니다. user 4개 insert JPQL을 이용해서 4번째 insert한 user의 name을 "changed na..
