꾸준함

트랜잭션과 락 1. 트랜잭션과 격리 수준트랜잭션은 ACID라 하는 원자성, 일관성, 격리성 그리고 지속성을 보장해야 함원자성 (Atomicity): 트랜잭션 낸 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하든가 모두 실패해야 함일관성 (Consistency): 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 함 i.g. DB에서 정한 무결성 제약 조건을 항상 만족해야 함격리성 (Isolation): 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리해야 함, 격리성은 동시성과 관련된 성능 이슈로 인해 격리 수준을 선택할 수 있음지속성 (Durability): 트랜잭션을 성공적으로 끝내면 해당 결과가 항상 기록되어 있어야 함, 중간에 시스템 문제가 발생하더라도 DB 로그 등을..

예외 처리 1. JPA 표준 예외 정리JPA 표준 예외들은 javax.persistence.PersistenceException의 자식 클래스이며 해당 예외 클래스는 RuntimeException의 자식따라서 JPA 예외는 모두 UncheckedException JPA는 표준 예외는 크게 두 가지로 나눌 수 있음트랜잭션 롤백을 표시하는 예외트랜잭션 롤백을 표시하지 않는 예외 트랜잭션 롤백을 표시하는 예외는 심각한 예외이므로 복구해서는 안됨해당 예외가 발생하면 트랜잭션을 강제로 커밋해도 트랜잭션이 커밋되지 않고 대신 javax.persistence.RollbackException 예외가 발생함  반면, 트랜잭션 롤백을 표시하지 않는 예외는 심각한 예외가 아님따라서 개발자가 트랜잭션을 커밋할지 롤백할지 판단..

컬렉션JPA는 자바에서 기본으로 제공하는 Collection, List, Set, Map 컬렉션을 지원하고 다음 경우에 해당 컬렉션을 사용할 수 있음@OneToMany, @ManyToMany를 사용해서 일대다나 다대다 엔티티 관계를 매핑할 때@ElementCollection을 사용해서 값 타입을 하나 이상 보관할 때 자바 컬렉션 인터페이스의 특징은 다음과 같음Collection: 자바가 제공하는 최상위 컬렉션, 하이버네이트는 중복을 허용하고 순서를 보장하지 않는다고 가정Set: 중복을 허용하지 않는 컬렉션, 순서를 보장하지 않음List: 순서가 있는 컬렉션이며 순서를 보장하고 중복을 허용Map: Key, Value 구조로 되어 있는 특수한 컬렉션  1. JPA와 컬렉션하이버네이트는 엔티티를 영속 상태로 ..

트랜잭션 범위의 영속성 컨텍스트순수 J2SE 환경에서 JPA를 사용하면 개발자가 직접 엔티티 매니저를 생성하고 트랜잭션도 관리해야 하지만스프링이나 J2EE 컨테이너 환경에서 JPA를 사용하면 컨테이너가 제공하는 전략을 따라야 함 1. 스프링 컨테이너의 기본 전략스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 디폴트로 사용해당 전략은 트랜잭션의 범위와 영속성 컨텍스트의 생존 범위가 같다는 뜻트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근  스프링 프레임워크를 사용하면 보통 비즈니스 로직을 시작하는 서비스 계층에 @Transactional 어노테이션을 선언해서 트랜잭션을 시작함외부에서는 단순히 서비스 ..

스프링 데이터 JPA 소개스프링 프레임워크에서 JPA를 편리하게 사용할 수 있도록 지원하는 프로젝트CRUD를 처리하기 위한 공통 인터페이스 제공레포지토리를 개발할 때 엔터피에스만 작성하면 실행 시점에 스프링 데이터 JPA가 구현 객체를 동적으로 생성해서 주입따라서 데이터 접근 계층을 개발할 때 구현 클래스 없이 인터페이스만 작성해도 개발을 완료할 수 있음   부연 설명일반적인 CRUD 메서드는 JpaRepository 인터페이스가 공통으로 제공하므로 문제가 없지만MemberRepository.findByUsername(...)처럼 공통으로 처리할 수 없어 직접 작성한 메서드는 스프링 데이터 JPA가 메서드명을 분석해서 다음 JPQL을 실행SELECT m FROM Member m WHERE username..

객체지향 쿼리 소개EntityManager.find() 메서드를 사용하면 식별자로 엔티티 하나를 조회 가능이렇게 조회한 엔티티에 객체 그래프 탐색을 사용하면 연관된 엔티티들을 찾을 수 있음식별자로 조회: EntityManager.find()객체 그래프 탐색: i.g. member.getTeam() 하지만 이 기능만으로는 애플리케이션을 개발하기 어려움ex) 나이가 30살 이상인 회원을 모두 검색하고 싶을 때 좀 더 현실적이고 복잡한 검색 방법 필요데이터는 DB에 있으므로 SQL로 필요한 내용을 최대한 걸러서 조회해야 하는데 ORM을 사용하면 DB 테이블이 아닌 엔티티 객체를 대상으로 개발하므로 검색도 테이블이 아닌 엔티티 객체를 대상으로 하는 방법이 필요 JPQL은 위와 같은 문제를 해결하기 위해 만들어졌..

기본값 타입아래 예제의 Member에서 String, int가 값 타입Member 엔티티는 id라는 식별자 값도 가지고 생명주기도 있지만값 타입인 name, age 속성은 식별자 값도 없고 생명주기도 회원 엔티티에 의존이에 따라 회원 엔티티 인스턴스를 제거하면 name, age 값도 제거됨  임베디드 타입 (복합 값 타입)임베디드 타입은 새로운 값 타입을 직접 정의해서 사용하는 것중요한 것은 직접 정의한 임베디드 타입 또한 int, String처럼 값 타입이라는 것 임베디드 타입 적용 전회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 그리고 주소 우편 번호를 멤버 변수로 가짐  임베디드 타입 적용 후앞선 설명은 단순히 정보를 풀어둔 것뿐근무 시작일과 우편번호는 서로 아무 관련이..

프록시엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것이 아님연관된 엔티티들이 사용되지 않음에도 불구하고 데이터베이스에서 연관된 엔티티를 함께 조회해 두는 것은 효율적이지 않음JPA는 위와 같은 문제를 해결하기 위해 엔티티가 실제 사용될 때까지 데이터베이스 조회를 지연하는 방법을 제공하는데 이것을 지연 로딩이라고 부름지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라 부름 1. 프록시 기초JPA에서 식별자로 엔티티 하나를 조회할 때는 `EntityManager.find()`를 사용해당 메서드는 영속성 컨텍스트에 엔티티가 없을 경우 데이터베이스를 조회이렇게 엔티티를 직접 조회할 경우 조회한 엔티티를 실제 사용하든 사용하지..

상속 관계 매핑관계형 데이터베이스에는 객체지향 언어에서 다루는 상속이라는 개념이 없지만슈퍼타입 서브타입 관계 (Super-Type Sub-Type Relationship)라는 모델링 기법이 객체의 상속 개념과 가장 유사함ORM에서 이야기하는 상속 관계 매핑은 객체의 상속 구조와 데이터베이스의 슈퍼타입 서브타입 관계를 매핑하는 것슈퍼타입 서브타입 논리 모델을 실제 모델인 테이블로 구현할 때는 다음과 같은 세 가지 방법을 선택 가능각각의 테이블로 변환: 각각을 모두 테이블로 생성하고 조회할 때 조인을 사용하며 JPA에서는 조인 전략이라고 부름통합 테이블로 변환: 테이블을 하나만 사용해서 통합하고 JPA에서는 단일 테이블 전략이라고 부름서브타입 테이블로 변환: 서브 타입마다 하나의 테이블을 생성하며 JPA에서..

다대일다대일 관계의 반대 방향은 항상 일대다 관계마찬가지로 일대다 관계의 반대 방향은 항상 다대일 관계데이터베이스 테이블의 1, 다 관계에서 외래 키는 항상 다쪽에 존재 (연관관계의 주인) 1. 다대일 단방향 [N:1]회원 엔티티와 팀 엔티티 코드를 통해 다대일 단방향 연관관계를 알아보겠습니다.회원은 Member.team으로 팀 엔티티를 참조할 수 있지만팀에는 회원을 참조하는 필드가 없기 때문에 다대일 단방향 연관관계@JoinColumn(name = "TEAM_ID")를 사용해서 Member.team 필드를 TEAM_ID 외래 키와 매핑했기 때문에 Member.team 필드로 회원 테이블의 TEAM_ID 외래키를 관리함   2. 다대일 양방향 [N:1, 1:N]다대일 양방향의 객체 연관관계에서 Membe..