본문 바로가기

분류 전체보기

(57)
영속성 컨텍스트? 1-1 영속성 컨텍스트의 정의 영속성 컨텍스트란 엔티티를 영구 저장하는 환경. persist() 메소드는 엔티티 매니저를 사용하여 엔티티를 영속성 컨테스트에 저장한다. 엔티티의 생명주기에는 4가지 상태가 있음. 각각 비영속, 영속, 준영속, 삭제 비영속 순수한 객체 상태. 영속성 컨텍스트나 DB와는 전혀 관련이 없음. // 객체를 생성한 상태 Member member = new Member(); member.setId("member1"); member.setUsename("회원1"); 영속 엔티티 매니저를 통해 영속성 컨텍스트에 저장. 영속성 컨텍스트가 관리하는 엔티티를 영속 상태라 함. 즉, 영속상태란 영속성 컨텍스트에 의해 관리 된다는 것. //객체를 저장한 상태(영속) em.persist(member); ..
JPA의 더티 체킹 JPA의 더티 체킹(Dirty Checking) 이터베이스의 엔티티 상태가 변경되었을 때 이를 자동으로 감지하여 업데이트하는 기능 JPA가 제공하는 영속성 컨텍스트의 한 기능으로, 엔티티의 상태를 관리하며, 트랜잭션이 종료될 때 변경된 엔티티를 데이터베이스에 자동으로 반영 함. 동작방식? 엔티티 조회 및 변경: 영속성 컨텍스트에 엔티티를 로드할 때, 해당 엔티티의 원본 상태를 스냅샷으로 보관 → 개발자가 엔티티의 상태를 변경하면, 이 변경 사항은 아직 데이터베이스에는 반영되지 않은 상태. 변경 감지: 트랜잭션이 종료되어 커밋되기 전, 영속성 컨텍스트는 엔티티의 현재 상태와 저장해둔 원본 스냅샷을 비교. 이 과정에서 변경된 부분을 감지 함. 더티 체킹 실행: 변경이 감지된 엔티티에 대해, JPA는 자동으로..
TIL 뉴스피드 KPT 회고 Keep - 현재 만족하고 있는 부분 박하은 커밋 룰과 코딩 컨벤션 등 협업을 위한 협의가 선행 된 점. 손준형 기획의 중요성을 알고 초반에 많은 시간 투자를 하여 원활하게 개발이 진행될 수 있었다. 권승준 매일 아침, 저녁으로 팀원들과 소통하는 시간에 서로의 진행 상황, 어려운 부분 등을 공유해서 좋았다. 미리 Git Rule이나 역할 등 확실한 기획을 하고 프로젝트를 시작해서 좋았다. 유선아 - 기능 구현에 앞서 기획을 할때, 어떤 기능들을 구현할지 미리 정하고, ERD, API 를 같이 고민하면서 작성하고, Repository rule(coding convention 및 commit rule)을 먼저 정한 다음. 역할을 잘 나누고 시작해서, 각자 맡은 부분을 merge 할 때 충돌이 덜 나는 등 훨..
N+1 문제 발생 이유 N+1 문제는 주로 ORM(Object-Relational Mapping) 툴을 사용할 때 발생한다. 예를 들어, 한 개의 부모 엔티티와 여러 개의 자식 엔티티가 있는 관계에서 부모 엔티티를 조회할 때 자식 엔티티들도 함께 조회하는 상황을 생각해 보자. 여기서 발생하는 문제는 아래와 같다. 먼저 부모 엔티티를 조회하는 쿼리 실행. (1번의 쿼리) 그 다음 각 부모 엔티티에 대응하는 자식 엔티티들을 조회하기 위해 부모 엔티티 수만큼 추가 쿼리를 실행. (N번의 쿼리) 결국, 부모 엔티티 1개를 조회하기 위해 1번의 쿼리가 실행되고, N개의 자식 엔티티를 조회하기 위해 추가로 N번의 쿼리가 실행되어 총 N+1번의 쿼리가 실행되는 것. 이는 데이터베이스에 과도한 부하를 주고 응답 시간을 증가시키는 ..
AOP, Interceptor, Filter AOP (Aspect-Oriented Programming) 개념: AOP는 관점 지향 프로그래밍으로, 애플리케이션의 핵심 로직에서 분리된 관심사( ex: 로깅, 보안, 트랜잭션 관리 등)를 모듈화하는 프로그래밍 패러다임. 역할: 메소드의 호출 전후, 예외 발생 등에 대한 공통 기능을 적용할 수 있다. 장점: 코드 중복을 줄이고, 핵심 로직과 공통 관심사를 분리하여 코드의 가독성과 유지보수성을 향상시킨다. Interceptor 개념: Interceptor는 특정 코드 조각( ex: 컨트롤러 메소드)이 호출되기 전후에 추가적인 작업을 수행하는 객체. 역할: 주로 MVC 모델에서 컨트롤러의 액션 처리 전후에 사용되며, 로깅, 인증, 권한 검사 등에 사용. 장점: 특정 컨트롤러나 액션에 대한 세밀한 제어가 가..
스프링의 Lifecycle 초기화 (Instantiation) Bean 정의: 스프링 설정 파일에 Bean이 정의되거나, 어노테이션을 통해 Bean이 정의 됨. Bean 인스턴스 생성: 스프링 컨테이너는 Bean 정의를 기반으로 Bean 인스턴스를 생성. 의존성 주입 (Dependency Injection): Bean이 다른 Bean에 의존하는 경우, 스프링은 의존성을 주입. Bean 초기화: Bean 인스턴스가 생성되고, 의존성이 주입된 후 초기화 메서드가 호출 됨. 이는 @PostConstruct 어노테이션 또는 XML 설정을 통해 정의될 수 있다. 사용 (Use) Bean 사용: 초기화된 Bean은 애플리케이션에서 필요에 따라 사용. Bean 생명주기 관리: 스프링 컨테이너는 Bean의 전체 생명주기 동안 Bean을 관리. ..
Call by reference - Java 스프링에서의 Call by Reference 특징 객체 전달: 스프링에서 객체를 함수나 메서드에 전달할 때, 실제 객체가 아닌 객체의 참조(메모리 주소)가 전달. 이것이 마치 "Call by Reference"처럼 작동한다. 원본 객체 수정: 메서드에 전달된 객체의 속성을 변경하면, 원본 객체에도 이 변경사항이 반영된다. 이는 메서드가 객체의 참조를 통해 원본 객체에 직접 접근하기 때문. 효율적인 메모리 사용: 객체의 실제 복사본을 만들지 않기 때문에, 메모리 사용이 더 효율적. 스프링에서의 사용 예시 의존성 주입(Dependency Injection): 스프링은 객체의 생성과 의존성 관리를 담당. 객체의 참조를 컨테이너로부터 주입받아 사용. 트랜잭션 관리: 스프링의 트랜잭션 관리 기능은 특정 메서드에 ..
오버라이드와 오버로드 오버라이드 (Override) 오버라이드는 자식 클래스가 부모 클래스에서 상속받은 메소드를 재정의하는 것. 상속: 오버라이드는 상속을 통해 이루어진다. 자식 클래스가 부모 클래스의 메소드를 재정의한다. 동일한 시그니처: 재정의하는 메소드는 부모 클래스의 메소드와 동일한 이름, 매개변수, 반환 타입을 가져야 함. 다형성: 오버라이드는 다형성의 한 예. 부모 클래스 타입의 변수가 자식 클래스의 오버라이드된 메소드를 호출할 수 있다. // 예시 코드 class Parent { void display() { System.out.println("Parent display()"); } } class Child extends Parent { @Override void display() { System.out.prin..