Spring

사용자 요청 -> 커넥션 조회 -> 드라이버 매니저 내부에서 db와 tcp/ip 커넥션 연결 -> 기타 부가정보를 DB에 전달 -> 아이디, 비밀번호를 통해 내부 인증 완료하고 DB 세션 생성 -> DB 드라이버가 커넥션 객체 생성해서 반환특징: 데이터베이스 커넥션 생

데이터베이스가 제공하는 트랜잭션은 두 작업이 모두 성공해야 저장하고, 중간에 하나라도 실패 시 전의 상태로 돌아가게 됨 모두 성공 시 Commit을 통해 정상 반영되고, 실패해서 이전으로 RollBack을 통해 되돌릴 수 있음원자성 : 트랜잭션 내에서 실행한 작업은 모

JDBC 표준 인터페이스 과거에는 애플리케이션 서버 입장에서 커넥션을 db와 연결 -> 각각의 데이터베이스 유형마다 연결 방식이 상이 -> 문제 해결을 위해 JDBC 표준 인터페이스 등장 JDBC 드라이버: JDBC 인터페이스를 각각의 DB 벤더에서 자신의 DB에 맞도

프레젠테이션 계층: ui와 관련된 처리, 웹 요청과 응답, 사용자 요청 검증서비스 계층: 비즈니스 로직 담당데이터 접근 계층: 실제 데이터베이스에 접근하는 코드 서비스 계층에 핵심 비즈니스 로직이 들어있으므로, 최대한 변경 없이 유지되도록 하기 위해 계층을 분리 데이터

Error : 애플리케이션에서 복구 불가능한 시스템 예외 -> catch 로 상위 예외를 잡으면 하위 예외까지 같이 잡히기 때문에 Exception부터 필요한 예외로 생각하고 잡으면 됨Exception: 체크 예외, 실질적 최상위 예외, 하위 예외까지 모두 컴파일러가

jpa에 대해 공부해보기 전에 기존에 사용하던 방식인 sql 중심 개발의 문제점, ORM, JPA의 장점 등에 대해 알아보려고 한다. 관계형 데이터베이스에서는 상속 개념이 없기 때문에 슈퍼타입, 서브타입 관계로 상속 관계를 표현해야 한다. 즉 각각의 테이블에 join

영속성 컨텍스트 엔티티 매니저 팩토리와 엔티티 매니저 고객 요청이 올때마다 Entity Manager Factory를 통해 EntityManager를 각각 생성해서 DB에 접근한다. 영속성 컨텍스트 > - 엔티티를 영구 저장하는 환경이다. 엔티티를

엔티티 매핑 종류 객체 테이블 매핑: @Entity, @Table 필드와 컬럼 매핑: @Coumn 기본키 매핑: @Id 연관관계 매핑 @Entity entity가 붙은 클래스는 JPA가 관리하는 엔티티임, 매핑할 클래스는 필수

스프링 프레임워크 등장 배경 EJB가 자바 진영의 표준 기술로 잘 되어있는 기술이었지만, 굉장히 복잡하고 느리기도 해서 공부하기 어려운 기술이었음 스프링의 등장: EJB 컨테이너를 대체할 수 있게 되었고, 단순하게 개발이 가능하여 현재 사실상 표준 기술이 되었음 > -

WAR 배포 방식의 단점 톰캣 같은 애플리케이션 서버(WAS)를 별도로 설치해야 한다. 애플리케이션 코드를 WAS로 빌드해야 하며, 빌드한 파일을 WAS에 배포해야 한다. 톰캣의 버전을 변경하려면 톰캣을 다시 설치해야 한다. 내장 서버와 외장 서버 이전에는 웹 애플리

서블릿 서블릿은 서버 소켓 연결.. 비즈니스 로직 실행 등까지 다 해줌 HttpServletRequest, HttpServletResponse 를 사용하면 HTTP 요청, 응답 정보 사용 가능 응답 메시지를 편리하게 사용할 수 있도록 해줌 -> 원하는 데이터를 Res

UMC 5주차 시니어 미션입니다. 키워드 정리 지연로딩과 즉시로딩의 차이 JPQL Fetch Join @EntityGraph commit과 flush 차이점 QueryDSL, OpenFeign의 QueryDSL N+1 문제 해결할 수 있는 여러 방안들 영속 상태의 종류 1. SQL 로그 분석 (spring.jpa.show-sql, logging.lev...

프로젝트가 너무 잘되어서, PM님이 날뛰고 계십니다.기존 기능에서, 가게를 검색하는 기능을 추가하신다고 합니다!!사용자가 원하는 가게 정보를 쉽고 정확하게 찾을 수 있도록 검색 API를 설계하고 구현해야합니다.검색 기능은 지역 필터, 이름 검색, 정렬 조건, 페이징을

500 에러를 처리하는 로직에서 알림 전송 로직을 추가한다.

UMC 4주차 시니어 미션 진행합니다. 1️⃣ 성능을 고려한 연관관계 매핑 & 최적화 적용@OneToMany 컬렉션을 조회할 때 List<MemberPrefer>를 Set<MemberPrefer>로 변경 후 차이점 분석데이터 정합성을 고려하여 orphanRe

UMC 4주차 시니어 미션 진행합니다. 하나의 트랜잭션에서 여러 엔티티를 처리하는 비즈니스 로직 작성예) Member가 탈퇴할 경우 관련된 모든 데이터를 삭제하는 API 구현@Transactional을 적용하고, @Modifying을 활용하여 Batch Delete 쿼

Page는 전체 데이터 개수, 전체 페이지 수, 현재 페이지 정보, 정렬 정보 등 추가적인 메타데이터를 모두 포함한다.Slice는 content + 다음 페이지 존재 여부만 알려주며, 전체 개수와 전체 페이지 수는 제공하지 않는다.전체 데이터 개수(totalElemen

독서 기록 생성 및 삭제 API를 구현하는데, 독서 기록에는 사진도 있고 내용도 존재한다. 지금 문제는, s3에 올라간 사진 delete를 하게 되면 DB 트랜잭션이랑 별개이기 때문에 @Transactional로 설정해둔 메서드 안에서 s3를 지우게 되면, 실패 시 롤

매월 1일에 생성되는 Report에서 OOM 원인을 분석하고, 스프링 배치 도입을 고려한다.OOM은 out of Memory로, 힙 메모리를 더 이상 확보하지 못해서 터지는 상황이다. 다음 코드에서 예상 원인의 흐름을 찾아보면 다음과 같다. findAll()로 유저를

자바 스프링 -> 코틀린 스프링으로 갈아타면서, Slf4j을 당연하게 사용했는데 코틀린은 롬북을 잘 사용하지 않기도 하고, 이참에 다른 로거와의 성능을 비교해서 써보자 하고 다른 로그 작성 방법을 찾아보게 되었다. 로그 수준에 따라서 로그가 남겨진다. 즉 logger.

User마다 한개씩만 생성되어야 하는 엔티티들이 있다. 기존에는 기본키를 따로 두고 user를 FK로 두는 방식으로 진행했다. 그렇지만 기본키를 많이 안쓰고 findByUserId 식의 메서드를 많이 사용한다면 컬럼 방비라고 생각하여 전략을 변경해보게 되었다. 기존 방

커서 페이징을 다시 보다가 갑자기 헷갈렸다.PageRequest.of(0, size)를 쓰면 offset이 0이니까 cursor 기반 조회에서 사실상 limit size처럼 동작하는 것 아닌가?그럼 Limit.of(size)랑 뭐가 다른가?또 Slice는 hasNext

이번에 테스트 환경을 보다가 찝찝한 지점이 있었다.운영은 PostgreSQL을 쓰고 있는데, 테스트는 H2의 PostgreSQL mode로 돌고 있었다.처음에는 PostgreSQL mode면 어느 정도 비슷하지 않나?라고 생각할 수 있다.그런데 Repository 테스

증상 생성/수정 후 Gemini 기반 패턴 분석을 비동기로 갱신하고 있었다.기존 흐름은 다음과 같았다.이 구조에는 두 가지 문제가 있었다.Gemini 호출이 DB 트랜잭션 안에서 실행된다.오래 걸린 이전 비동기 작업이 나중에 끝나면서 최신 분석 결과를 덮어쓸 수 있다.

sealed class는 상속 가능한 범위를 같은 파일로 제한하는 클래스다.컴파일러가 모든 하위 타입을 알고 있기 때문에, when 분기에서 else 없이도 모든 케이스를 강제 처리할 수 있다.나중에 Triangle을 추가하면, 처리하지 않은 when에서 즉시 컴파일