조회만 하는 쿼리에 @Transactional(readOnly = true) 사용@Transactional(readOnly = true)public UserDto getUser(Long id) { return userRepository.findById(id);} 🔹 readOnly = true 를 붙이면 다음과 같은 이점이 있어요:효과 설명Flush 방지JPA는 트랜잭션 커밋 전에 변경사항을 flush함 → readOnly면 생략성능 최적화Hibernate, JPA가 dirty checking을 하지 않음일부 DB 드라이버 최적화(예: Oracle) 읽기 전용 힌트를 전달하기도 함명시적 의미 전달해당 메서드는 ..

✅ Lazy Loading이란?연관된 엔티티를 즉시 가져오지 않고, 실제로 사용할 때(load 시점에) 쿼리를 날려서 로딩하는 방식입니다.즉,A 객체를 가져오면서,A가 가지고 있는 B 객체(예: 연관된 리스트, 다른 엔티티)는 “지금 필요 없으면 안 가져옴”대신, 진짜 그걸 사용할 때 SELECT 쿼리를 실행해서 가져옴 ✅ 예시@Entitypublic class User { @OneToMany(mappedBy = "user", fetch = FetchType.LAZY) private List orders;}@Transactionalpublic void example() { User user = userRepository.findById(1L).get(); // 여기서 orders는 로딩..

✅ @Transactional이 있으면 JPA에 어떤 일이 벌어지나?항목설명트랜잭션 시작@Transactional 메서드가 호출되면, Spring이 트랜잭션 시작영속성 컨텍스트 생성트랜잭션과 함께 1차 캐시(Persistence Context) 생성됨 (엔티티 관리 시작)엔티티 저장 및 변경 감지 가능persist(), findById(), setXxx() 등으로 관리되는 엔티티 감시 가능dirty checking 작동트랜잭션 종료 전, 변경된 엔티티를 자동 감지하여 UPDATE 쿼리 생성flush 자동 실행트랜잭션 커밋 직전에 변경사항을 DB에 반영 (flush)commit 또는 rollback예외 발생 여부에 따라 commit 또는 rollback영속성 컨텍스트 종료트랜잭션 끝나면서 영속성 컨텍스트도..

❌ 1. 배치 Insert 불가설명:JPA에서는 보통 여러 엔티티를 persist() 하면, 영속성 컨텍스트에 저장되었다가 flush() 시점에 한꺼번에 DB에 INSERT 됩니다.하지만 IDENTITY는 @GeneratedValue(strategy = IDENTITY) 덕분에 DB에 insert 하지 않으면 id 값을 알 수 없습니다.➤ 결과em.persist(entity) 호출 시마다 즉시 insert 쿼리가 나가고,DB로부터 생성된 PK를 받아와야 다음 단계로 넘어갈 수 있습니다.➤ 그래서 생기는 문제JPA는 insert 쿼리를 모아서 배치로 보낼 수 없고,매 insert마다 DB round-trip이 발생합니다.➤ 예시for (int i = 0; i IDENTITY: insert 쿼리 100번 발..