일단 숫자 크기를 보니 O(n)으로는 절대 안 된다는 건 알겠다. 그래서 내린 결론은? 이분탐색 인데... 뭘 기준으로 이분탐색을 진행할지 고민을 많이 했던 것 같다. 일단 결론은 모든 놀이기구를 타는 시간을 기준으로 해결하였다. minT=0maxT=n*max(times) # 놀이기구 타는 최대 시간 최대 시간을 어떤 식으로 잡을까 하다가 n명이 가장 시간이 오래 걸리는 놀이기구 max(times)를 탄다고 생각하면 될 것 같아 n*max(times)로 최대 시간을 표현해보았다. 그다음엔 n명을 처리가능한 최소 시간을 찾아보겠다. 물론 이분탐색으로 찾는 거다. retT=0 # n명 처리 가능한 최소 시간while minT 여기에서 핵심 포인트는 처리 가능한 사람 수를 찾는 로직인데, 첨에 생각할 때는 예..

아 맞다 그런게 있었지  Record는 Java 16에서 정식 출시된 새로운 유형의 클래스로 모든 필드가 final 키워드로 선언되기 때문에 불변성(Immutable)의 특징이 존재한다. 또한 자동으로 생성자, getter, equals, hashCode, toString 등의 메서드를 자동으로 생성해준다. // 생성자, getter, hashCode(), equals(), toString() 자동 완성public record MemberDto(String name, String email, int age) {}  특히 계층 간 데이터 전송을 목적으로 하는 DTO로 사용될 수 있으며 자동으로 여러 메서드를 생성해주기 때문에 보일러 플레이트 코드를 줄일 수 있다.  그렇지만 Record는 다른 클래스를 상..

일단 결론부터 말하자면 트랜잭션이 동작하지 않는다.  @Transaction 과 같은 어노테이션들은 모두 런타임에 동작하는 Spring AOP를 기반으로 동작하는데 Spring AOP에서는 어노테이션이 붙어있는 타겟 클래스의 프록시를 만들어 해당 타겟 클래스의 메서드 수행 전후에 일련의 처리를 한다. 이때 타겟 클래스의 타입에 따라 인터페이스 기반의 프록시 생성 시 JDK Dynamic Proxy, 그 외에는 CGLIB을 사용한다고 한다.  우선 Spring이 빈 생성시 해당 빈에 AOP 어노테이션이 있는지 확인하고 만약 있다면 프록시 객체를 생성하여 빈을 대체한다. 이때 위에서 말한 JDK Dynamic Proxy의 경우 인터페이스의 public 메서드, CGLIB의 경우 private를 제외한 pub..

두 엔티티 간에 영속성 전이가 제대로 이루어지려면?현재 진행하고 있는 개인 프로젝트에서 다음과 같이 엔티티들의 연관관계가 설정되어 있다. Member -- (OneToMany) -- History -- (OneToMany) -- Question 그리고 저장 및 테스트를 용이하게 하기 위해 Member에dockerel.tistory.com N+1 문제 해결 후기는 위 글과 이어집니다. 엔티티 영속성 전이 문제를 어찌어찌 해결한 후 한시름 놨다고 생각할 때쯤 쿼리 로그를 보니 뭔가 이상했다.  무수한 SELECT 요청이 날아가고 있었고, 딱 보자마자 N+1 문제라는 느낌이 확 왔다. 그런데 사실 그도 그럴 것이 기존에 멤버가 질문한 개수를 구하는 로직은 이렇게 작성되어 있었다.  멤버의 history를 구하..

현재 진행하고 있는 개인 프로젝트에서 다음과 같이 엔티티들의 연관관계가 설정되어 있다. Member -- (OneToMany) -- History -- (OneToMany) -- Question 그리고 저장 및 테스트를 용이하게 하기 위해 Member에서 Question까지 CascadeType.ALL을 통해  영속성 전이를 설정해 놓았다. 그리고 Member, History 그리고 Question을 저장하고 Member가 올린 총 Question의 수를 구해오는 테스트를 작성하였다. @DisplayName("유저가 존재하면 유저의 이메일, 닉네임, 가입날짜, 해당 유저의 질문 개수를 반환한다.")@Testvoid getMyInfoWithExistMemberId() { // given Stri..

CORS(Cross Origin Resource Sharing)은 출처가 다른 리소스를 요청할 때 접근 권한을 부여하는 메커니즘으로 리소스를 주고받는 두 곳의 출처가 다르면 출처가 교차(Cross Origin)한다고 말한다. 이때 출처는 URL, 프로토콜 그리고 포트까지 포함되며 서버에서 허용하지 않은 클라이언트가 요청을 할 시에 CORS 에러가 발생할 수 있다. CORS가 필요한 이유? 이전에는 CSRF(Cross-Site Request Forgery) 문제가 있었다.   공격자에 의해 사용자가 가짜 요청을 날리게 되는 공격으로, 위 그림에서는 공격자가 만든 가짜 사이트로 인해 피해자가 자신의 정보를 이용하여 돈을 이체하게 된다.  이를 막기 위해 SOP(Same-Origin Policy)를 구현하였다..

저번 포스팅에서 MVCC 사용 시 팬텀 리드가 발생할 수 있는데 이를 갭 락과 넥스트키 락으로 해결할 수 있다고 했다. 이에 대해 좀 더 자세히 알아보자.  데이터베이스 시스템에서 동시성을 제어하는 방법은?데이터베이스 시스템에서 동시성을 제어하는 방법으로는 MVCC(Multi-Version Concurrency Control)과 Lock-Based Concurrency Control이 있다. MVCC(Multi-Version Concurrency Control)  MVCC는 데이터의 여러 버전을 유지하여dockerel.tistory.com 팬텀 리드란?  팬텀 리드(Phantom Read)란 트랜잭션이 동일한 조건의 쿼리를 반복해서 실행할 때 처음 실행했을 때의 결과에서 존재하지 않았던 새로운 행이 나타..

데이터베이스 시스템에서 동시성을 제어하는 방법으로는 MVCC(Multi-Version Concurrency Control)과 Lock-Based Concurrency Control이 있다. MVCC(Multi-Version Concurrency Control)  MVCC는 데이터의 여러 버전을 유지하여 트랜잭션이 동시에 데이터를 쓰고 읽을 수 있다. 즉, 각 트랜잭션은 각자만의 스냅샷을 기반으로 데이터를 읽는다. 하지만 이러한 특징 때문에 만약 T1 트랜잭션에서 쓰기 작업을 하고 커밋하지 않은 상태에서 T2에서 해당 변경 사항을 보지 못한다.  MVCC는 읽기 작업 시 락을 사용하지 않아 높은 동시성을 제공한다. 즉 읽기 작업은 락에 의해 지연되지 않아 읽기 위주의 작업이 많은 애플리케이션에서 좋은 성능..