✔️ 데이터 접근 기술 - 베이스

용어 정리

SQL Mapper

• JdbcTemplate, MyBatis
• 개발자는 SQL만 작성하면 해당 SQL의 결과를 객체로 편리하게 매핑해준다.
• JdbcTemplate은 여러가지 중복코드들을 제거해준다.

ORM

• JPA, Hibernate, 스프링 데이터 JPA, Querydsl
• 기본적인 SQL은 JPA가 대신 작성하고 처리해준다.
• JPA는 자바 진영의 ORM 표준이고 Hibernate는 JPA에서 가장 많이 사용하는 구현체이다.

DTO

• Data Transfer Object
• 기능은 없고 데이터를 전달하는 용도로 사용되는 객체
• DTO가 사용되는 엔드포인트에 선언하면된다.

@EventListener

• @EventListener(ApplicationReadyEvent.class) : 스프링 컨테이너가 완전히 초기화를 다 끝내고 실행 준비가 되었을 떄 발생하는 이벤트이다.

  • 이 기능 대신 @PostContruct 를 사용할 경우 AOP 같은 부분이 다 처리되지 않은 시점에 호출될 수 있기 때문에, 문제가 발생할 수 있다.

    @Slf4j
    @RequiredArgsConstructor
    public class TestDataInit {
     private final ItemRepository itemRepository;
     /**
     확인용 초기 데이터 추가
     */
     @EventListener(ApplicationReadyEvent.class)
     public void initData() {
    	 itemRepository.save(new Item("itemA", 10000, 10));
    	 itemRepository.save(new Item("itemB", 20000, 20));
     }
    }

ItemServiceApplication 설정 + 프로필

@Import(MemoryConfig.class)
@SpringBootApplication(scanBasePackages = "hello.itemservice.web")
public class ItemServiceApplication {

	public static void main(String[] args) {
		SpringApplication.run(ItemServiceApplication.class, args);
	}

	@Bean
	@Profile("local")
	public TestDataInit testDataInit(ItemRepository itemRepository) {
		return new TestDataInit(itemRepository);
	}

}

• @Import(MemoryConfig.class) : 앞서 설정한 MemoryConfig 를 설정 파일로 사용한다.
• scanBasePackages = "hello.itemservice.web" : 컴포넌트 스캔 경로 - 해당 패키지부터 하위 모든 클래스

프로필

• @Profile("local") : 특정 프로필의 경우에만 스프링 빈으로 등록한다.
• 스프링은 로딩 시점에 application.properties의 spring.profiles.active 속성을 읽어서 프로필로 사용한다.
• 프로필은 로컬, 운영 환경, 테스트 실행 등 다양한 환경에 따라서 다른 설정을 할 때 사용한다.
• 설정하지 않는다면 default 라는 프로필로 실행

✔️ 스프링 JdbcTemplete

JdbcTemplete 정리

장점

• 설정의 편리함
  • JdbcTemplate은 spring-jdbc 라이브러리에 포함되어 있는데 이 라이브러리는 스프링으로 JDBC를 사용할 때 기본으로 사용되는 라이브러리이다.
• 반복 문제 해결
  • 템플릿 콜백 패턴을 통해 반복 작업을 대신 처리해준다.
    • 커넥션 흭득
    • statement 준비, 실행
    • 결과를 반복하도록 루프를 실행
    • 커넥션 종료, statement, resultset 종료
    • 트랜잭션을 다룩 위한 커넥션 동기화
    • 예외 발생시 스프링 예외 변환기 실행

단점

• 동적 SQL을 해결하기 어렵다.

구현 - V1

코드

@Slf4j
public class JdbcTemplateItemRepositoryV1 implements ItemRepository {

    private final JdbcTemplate template;

    public JdbcTemplateItemRepositoryV1(DataSource dataSource) {
        this.template = new JdbcTemplate(dataSource);
    }

    @Override
    public Item save(Item item) {
        String sql = "insert into item (item_name, price, quantity) values (?, ?, ?)";
        KeyHolder keyHolder = new GeneratedKeyHolder();
        template.update(con -> {
            PreparedStatement ps = con.prepareStatement(sql, new String[]{"id"});
            ps.setString(1, item.getItemName());
            ps.setInt(2, item.getPrice());
            ps.setInt(3, item.getQuantity());
            return ps;
        }, keyHolder);

        Long key = keyHolder.getKey().longValue();
        item.setId(key);
        return item;
    }

    @Override
    public void update(Long itemId, ItemUpdateDto updateParam) {
        String sql = "update item set item_name=?, price=?, quantity=? where id=?";
        template.update(sql, updateParam.getItemName(), updateParam.getPrice(), updateParam.getQuantity(), itemId);
    }

    @Override
    public Optional<Item> findById(Long id) {
        String sql = "select id, item_name, price, quantity from item where id=?";
        try{
            Item item = template.queryForObject(sql, itemRowMapper(), id);
            return Optional.of(item);
        } catch (EmptyResultDataAccessException e){
            return Optional.empty();
        }
    }

    @Override
    public List<Item> findAll(ItemSearchCond cond) {
        String itemName = cond.getItemName();
        Integer maxPrice = cond.getMaxPrice();
        String sql = "select id, item_name, price, quantity from item";
        //동적 쿼리
        if (StringUtils.hasText(itemName) || maxPrice != null) {
            sql += " where";
        }
        boolean andFlag = false;
        List<Object> param = new ArrayList<>();
        if (StringUtils.hasText(itemName)) {
            sql += " item_name like concat('%',?,'%')";
            param.add(itemName);
            andFlag = true;
        }
        if (maxPrice != null) {
            if (andFlag) {
                sql += " and";
            }
            sql += " price <= ?";
            param.add(maxPrice);
        }
        log.info("sql={}", sql);
        return template.query(sql, itemRowMapper(), param.toArray());
    }

    private RowMapper<Item> itemRowMapper() {
        return ((rs, rowNum) -> {
            Item item = new Item();
            item.setId(rs.getLong("id"));
            item.setItemName(rs.getString("item_name"));
            item.setPrice(rs.getInt("price"));
            item.setQuantity(rs.getInt("quantity"));
            return item;
        });
    }
}

Save 메서드

• 데이터를 저장할 때 PK 생성에 identity (auto increment) 방식을 사용하기 때문에 PK인 값을 비워두고 저장해야 한다.
  • KeyHolder 와 connection.prepareStatement(sql, new String[]{"id}) 를 사용해서 id를 지정해주면 Insert 쿼리 실행 이후에 데이터베이스에서 생성된 ID값을 참조할 수 있다.
  • 뒤에서 설명할 SimpleJdbcTemplate 을 사용하면 더 편리하다

FindById 메서드

• template.queryForObject()
  • 결과 로우가 하나일 때 사용한다.
  • ResultSet을 객체로 변환하는 RowMapper를 인자로 넣어줘야한다.
  • 결과가 없으면 EmptyResultDataAccessException 예외가 발생한다.
  • 결과가 둘 이상이면 IncorrectResultSizeDataAccessException 예외가 발생한다.

※ JdbcTemplate은 dataSource를 사용하는데 스프링 부트는 application.properties에 설정 정보만 넣어 놓으면 해당 설정을 사용해서 커넥션 풀과 DataSource, 트랜잭션 매니저를 스프링 빈으로 자동 등록한다. → 스프링 부트의 자동 리소스 등록

NamedParameterJdbcTemplate - V2

• 이름 지정 파라미터
  • 파라미터를 전달하려면 Map처럼 Key, Value 데이터 구조를 만들어서 전달해야 한다.
  • 이름 지정 바인딩에서 자주 사용하는 파라미터의 종류는 아래의 3가지 이다.
• SQL 문에서 ?로 되어 있는 부분을 :Key값 형태로 바꿔준다.

1.BeanPropertySqlParamterSource

• 자바빈 프로퍼티 규약을 통해서 자동으로 파라미터 객체를 생성한다.
  • getXxx() -> xxx, getItemName() -> itemName
  • SQL문의 인자로 들어가는 값 모두가 Dto 인자로 들어올 경우에만 사용가능

SqlParameterSource param = new BeanPropertySqlParameterSource(item);

2.MapSqlParamterSource, 3.Map

SqlParameterSource param = new MapSqlParameterSource()
                .addValue("itemName", updateParam.getItemName())
                .addValue("price", updateParam.getPrice())
                .addValue("quantity", updateParam.getQuantity())
                .addValue("id", itemId);

Map<String, Object> param = Map.of("id", id);

BeanPropertyRowMapper

private RowMapper<Item> itemRowMapper() {
        return BeanPropertyRowMapper.newInstance(Item.class);
}

별칭

• select item_name 의 경우 setItem_name() 이라는 메서드 없기 때문에 Param을 받을 때 문제가 생긴다. 이런 경우 개발자가 SQL을 다음과 같이 as 를 사용해서 고치면 된다.
  • select item_name as itemName
  • 하지만 BeanPropertyRowMapper 는 언더스코어 표기법을 카멜 표기법으로 변환해주기 때문에 컬럼 이름과 객체 이름이 완전히 다른 경우에만 as를 사용하면 된다.

관례의 불일치

• 자바 객체는 카멜 표기법을 사용하고 관계형 데이터베이스에서는 주로 언더스코어 표기법을 사용한다.

SimpleJdbcInsert - V3

• 코드

  @Slf4j
  public class JdbcTemplateItemRepositoryV3 implements ItemRepository {
  
      private final NamedParameterJdbcTemplate template;
      private final SimpleJdbcInsert simpleJdbcInsert;
  
      public JdbcTemplateItemRepositoryV3(DataSource dataSource) {
          this.template = new NamedParameterJdbcTemplate(dataSource);
          this.simpleJdbcInsert = new SimpleJdbcInsert(dataSource)
                  .withTableName("item")
                  .usingGeneratedKeyColumns("id");
      }
  
      @Override
      public Item save(Item item) {
          SqlParameterSource param = new BeanPropertySqlParameterSource(item);
          Number key = simpleJdbcInsert.executeAndReturnKey(param);
          item.setId(key.longValue());
          return item;
      }
  }

• withTableName: 데이터를 저장할 테이블 명을 지정한다.
• usingGeneratedKeyColumns: key를 생성하는 PK 컬럼 명을 지정한다.
• SimpleJdbcInsert는 생성 시점에 데이터베이스 테이블의 메타 데이터를 조회한다. 따라서 어떤 칼럼이 있는지 확인 할 수 있으므로 usingColumns를 생략할 수 있다.

✔️ DB관련 테스트

DB 연동

• 데스트 케이스는 src/test 에 있기 때문에 그 하위에 있는 [application.properties](http://application.properties) 파일이 우선순위를 가지고 실행된다.
  • 해당 파일에 DB 설정 정보를 추가한다.

SpringBootTest

• @SpringBootTest Annotation은 @SpringBootApplication을 찾아서 설정으로 사용한다.
  • 현재 DB설정이 @Import(JdbcTemplateV3Config.class) 로 설정되어 있기 때문에 JdbcTemplate을 통해 데이터베이스를 호출하게 된다.

DB 분리

• 로컬에서 사용하는 애플리케이션 서버와 테스트에서 같은 데이터베이스를 사용하는 경우 이미 존재하는 데이터들로인해 에러가 발생할 수 있다.
• 이렇게 DB를 분리했지만 테스트를 2번 실행하는 경우 데이터를 중복으로 인해 에러가 발생한다.

테스트의 중요 원칙

1. 테스트는 다른 테스트와 격리해야 한다.
2. 테스트는 반복해서 실행할 수 있어야 한다.

데이터 롤백

• 위의 문제점을 트랜잭션을 통해 해결할 수 있다.
• 테스트가 끝나고 나서 트랜잭션을 강제로 롤백하면 데이터가 제거된다.
• 중간에 테스트가 실패해서 롤백에 실패해도 커밋이 되지 않았기 때문에 데이터베이스에 데이터가 반영되지 않는다.

BeforeEach, AfterEach를 통한 직접 구현 - 코드

@SpringBootTest
class ItemRepositoryTest {

    @Autowired
    ItemRepository itemRepository;

    @Autowired
    PlatformTransactionManager transactionManager;
    TransactionStatus status;

    @BeforeEach
    void beforeEach(){
        //트랜잭션 시작
        status = transactionManager.getTransaction(new DefaultTransactionDefinition());
    }
    @AfterEach
    void afterEach() {
        //MemoryItemRepository 의 경우 제한적으로 사용
        if (itemRepository instanceof MemoryItemRepository) {
            ((MemoryItemRepository) itemRepository).clearStore();
        }
        //트랜잭션 롤백
        transactionManager.rollback(status);
    }
}

• PlatformTransactionManager를 주입받아 각 테스트 전에 getTransaction을 통해 트랜잭션을 시작하고 테스트가 끝나면 RollBack 한다.

Transactional Annotation을 통한 구현

• 클래스 또는 메서드에 @Transactional을 붙이면 된다.
• 원래 @Transactional은 로직이 성공적으로 수행되면 커밋되지만 테스트에서 사용할 경우에는 테스트를 트랜잭션 안에서 실행하고, 테스트가 끝나면 자동으로 롤백시킨다.

※ 테스트와 애플리케이션 서버, 둘 다에서 @Transactional이 사용되는 경우에 대해서는 뒤에서 다룰 예정이다.

• 가끔 데이터베이스에 데이터가 잘 보관되었는지 결과를 눈으로 확인하고 싶을 경우
  • 해당 메서드에 @Commit 또는 @Rollback(false) 를 붙여주면 된다.

임베디드 모드 DB

임베디드 모드

• H2 데이터베이스는 자바로 개발되어 있고, JVM안에서 메모리 모드로 동작하는 특별한 기능을 제공한다. 그래서 애플리케이션을 실행할 때 H2 데이터베이스도 해당 JVM메모리에 포함해서 함께 실행할 수 있다.
• DB를 애플리케이션에 내장해서 함께 실행한다고 해서 임베디드 모드라 한다.

직접 설정

• ItemServiceApplication에 Bean Annotaion과 Test Profile을 통해 직접 등록한다.

  	@Bean
  	@Profile("test")
  	public DataSource dataSource(){
  		DriverManagerDataSource dataSource = new DriverManagerDataSource();
  		dataSource.setDriverClassName("org.h2.Driver");
  		dataSource.setUrl("jdbc:h2:mem:db;DB_CLOSE_DELAY=-1");
  		dataSource.setUsername("sa");
  		dataSource.setPassword("");
  		return dataSource;
  	}

• 메모리 DB는 서버가 꺼질 때마다 완전히 다운되는 것이기 때문에 테스트를 실행하기 전에 항상 테이블을 먼저 생성해주어야 한다.
  • JdbcTemplate을 직접 사용해서 테이블을 생성하는 DDL을 호출해도 되지만 너무 불편하다.
  • 스프링 부트는 SQL 스크립트를 실행해서 애플리케이션 로딩 시점에 데이터베이스를 초기화하는 기능을 제공한다.
  • src/test/resources/schema.sql 을 생성하고 코드를 작성한다.

    drop table if exists item CASCADE;
    create table item
    (
        id bigint generated by default as identity,
        item_name varchar(10),
        price integer,
        quantity integer,
        primary key (id)
    );

스프링 부트 사용

• 테스트 application.properties에 DB 설정정보를 삭제하고 ItemServiceApplication에 등록한 빈 또한 제거한 후 별다른 정보가 없으면 스프링 부트는 임베디드 모드로 접근하는 데이터소스를 만들어서 제공한다.

✔️ MyBatis

장점

• SQL 문을 xml 파일에 편하게 작성할 수 있다.
  • JdbcTemplate의 경우 문장이 길어질 경우 +를 통해 붙여야하는 불편함이 있었음
• 태그를 이용해서 동적 쿼리를 편하게 작성할 수 있다.

단점

• JdbcTemplate은 스프링에 내장된 기능이고, 별도의 설정없이 사용할 수 있지만 MyBatis는 약간의 설정이 필요하다.

설정

#application.properties  MyBatis
mybatis.type-aliases-package=hello.itemservice.domain
mybatis.configuration.map-underscore-to-camel-case=true
logging.level.hello.itemservice.repository.mybatis=trace

• mybatis.type-aliases-package
  • 마이바티스에서 타입 정보를 사용할 때는 패키지 이름을 적어주어야 하는데, 여기에 명시하면 패키지 이름을 생략할 수 있다.
  • 지정한 패키지와 그 하위 패키지가 자동으로 인식된다.
  • 여러 위치를 지정하려면 , , ; 로 구분하면 된다.
• mybatis.configuration.map-underscore-to-camel-case
  • JdbcTemplate의 BeanPropertyRowMapper 에서 처럼 언더바를 카멜로 자동 변경해주는 기능을 활성화 한다.
• logging.level.hello.itemservice.repository.mybatis=trace
  • MyBatis에서 실행되는 쿼리 로그를 확인할 수 있다

적용

ItemMapper 인터페이스

@Mapper
public interface ItemMapper {
    void save(Item item);
    void update(@Param("id") Long id, @Param("updateParam")ItemUpdateDto updateParam);
    Optional<Item> findById(Long id);
    List<Item> findAll(ItemSearchCond itemSearchCond);
}

• 마이바티스 매핑 XML을 호출해주는 매퍼 인터페이스를 선언해준다.
• 이 인터페이스에는 MyBatis가 인식할 수 있도록 @Mapper를 붙여준다.
• 이 인터페이스의 메서드를 호출하면 리소스 패키지 아래 같은 경로로 설정한 Xml 파일을 읽어서 해당 SQL을 실행하고 결과를 반환한다.

XML 파일

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="hello.itemservice.repository.mybatis.ItemMapper">
    <insert id="save" useGeneratedKeys="true" keyProperty="id">
        insert into item(item_name, price, quantity)
        values (#{itemName}, #{price}, #{quantity})
    </insert>

    <update id="update">
        update item
        set item_name=#{updateParam.itemName},
            price=#{updateParam.price} ,
            quantity=#{updateParam.quantity}
        where id=#{id}
    </update>

    <select id="findById" resultType="Item">
        select id, item_name, price, quantity
        from item
        where id=#{id}
    </select>

    <select id="findAll" resultType="Item">
        select id, item_name, price, quantity
        from item
        <where>
            <if test="itemName != null and itemName != ''">
                and item_name like concat('%',#{itemName},'%')
            </if>
            <if test="maxPrice !=null">
                and price &lt;= #{maxPrice}
            </if>
        </where>
    </select>
</mapper>

• namespace : 앞서 만든 메퍼 인터페이스를 지정해주면 된다.

※ XML 파일의 경로를 수정하고 싶다면 application.properties에 mybatis.mapper-location=classpath:mapper/**/*.xml 을 설정해주면 된다.

• 이렇게 하면 resource/mapper 를 포함한 하위 폴에 있는 XML을 XML 매핑 파일로 인식
• finById
  • resultType 에는 반환 타입을 명시한다.
    • application.properties에 mybatis.type-aliases-package=hello.itemservice.domain 속성을 지정한 덕분에 모든 패키지명을 다 적지 않아도 된다.

특수문자 사용

• xml에서 <, > 해당 문자는 태그에 해당되기 때문에 사용하기 위해서는 다른 방법을 사용해야한다.
  • 문자 사용

    < : <
    : >
    & : &

  • CDATA 사용

    <![CDATA[
     and price <= #{maxPrice}
     ]]>

원리

### 매퍼 구현체

• 매퍼 구현체는 예외 변환까지 처리해준다.
  • MyBatis에서 발생한 예외를 스프링 예외 추상화인 DataAccessExeption 에 맞게 변환해서 반환해준다.

기타기능

• PDF 참고

✔️ JPA

이론 정리

• 객체를 관계형 DB에 저장해야하는데 이 둘 사이에는 차이점이 존재한다.
  • 상속
  • 연관관계
  • 데이터 타입
  • 데이터 식별 방법
• 그렇기 때문에 객체답게 모델링 할수록 매핑 작업만 늘어난다.
• 객체를 자바 컬렉션에 저장 하듯이 DB에 저장하는 방법 → JPA(Java Persistence APIp)
  • 객체는 객체대로 설계
  • 관계형DB는 관계형DB대로 설계

JPA를 사용하는 이유

• SQL 중심적인 개발에서 객체 중심으로 개발
• 생산성, 유지보수
• 패러다임의 불일치 해결
• 성능
  1. 1차 캐시와 동일성 보장
     • 같은 트랜잭션 안에서는 같은 엔티디를 반환
     • DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장
  2. 트랜잭션을 지원하는 쓰기 지원
     • 트랜잭션을 커밋할 때까지 INSERT SQL을 모음
     • JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송
     • Update, Delete로 인한 로우락 시간 최소화
  3. 지연 로딩
• 데이터 접근 추상화와 벤더 독립성

적용

Item Class

@Data
@Entity
public class Item {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "item_name", length = 10)
    private String itemName;
    private Integer price;
    private Integer quantity;

    public Item() {
    }

    public Item(String itemName, Integer price, Integer quantity) {
        this.itemName = itemName;
        this.price = price;
        this.quantity = quantity;
    }
}

• @Entity : JPA가 사용하는 객체라는 뜻
• @Id: 테이블의 PK와 해당 필드를 매핑한다.
• @Column : 객체의 필드를 테이블의 컬럼과 매핑한다.
  • name 속성으로 테이블 컬럼이름을 지정할 수 있다.
  • @Column을 생략하면 필드의 이름을 테이블 컴럼 이름으로 사용하는데 객체 필드의 카멜케이스를 테이블 컬럼의 언더스코어로 자동 변환해주기 때문에 itemName 같은 경우 @Column을 생략해도 된다.
• JPA는 public 또는 protected 기본 생성자가 필수이다.

JPAItemRepository 코드

@Repository
@Transactional
@RequiredArgsConstructor
public class JpaItemRepositoryV1 implements ItemRepository {

    private final EntityManager em;

    @Override
    public Item save(Item item) {
        em.persist(item);
        return item;
    }

    @Override
    public void update(Long itemId, ItemUpdateDto updateParam) {
        Item item = em.find(Item.class, itemId);
        item.setItemName(updateParam.getItemName());
        item.setPrice(updateParam.getPrice());
        item.setQuantity(updateParam.getQuantity());
    }

    @Override
    public Optional<Item> findById(Long id) {
        Item item = em.find(Item.class, id);
        return Optional.ofNullable(item);
    }

    @Override
    public List<Item> findAll(ItemSearchCond cond) {
        String jpql = "select i from Item i";

        String itemName = cond.getItemName();
        Integer maxPrice = cond.getMaxPrice();

        if (StringUtils.hasText(itemName) || maxPrice != null) {
            jpql += " where";
        }

        boolean andFlag = false;
        if (StringUtils.hasText(itemName)) {
            jpql += " i.itemName like concat('%',:itemName,'%')";
            andFlag = true;
        }
        if (maxPrice != null) {
            if (andFlag) {
                jpql += " and";
            }
            jpql += " i.price <= :maxPrice";
        }
        TypedQuery<Item> query = em.createQuery(jpql, Item.class);
        if (StringUtils.hasText(itemName)) {
            query.setParameter("itemName", itemName);
        }
        if (maxPrice != null) {
            query.setParameter("maxPrice", maxPrice);
        }
        return query.getResultList();
    }
}

• EntityManager 주입
  • JPA는 모든 동작을 엔티티 매니저를 통해서 이루어진다.
  • 엔티디 매니저는 내부에 데이터 소스를 가지고 있고, 데이터베이스에 접근할 수 있다.
• @Transactional
  • JPA의 모든 데이터 변경은 트랜잭션 안에서 이루어져야 한다. 보통의 경우 Service 계층에서 Transactional을 걸어주는게 일반적이다. 이 프로젝트만 예외

※ JPA를 설정하려면 EntityManagerFactory, JPA 트랜잭션 매니저, 데이터소스 등등 다양한 설정을 해야 한다. 하지만 스프링 부트는 이 과정을 모두 자동화 해준다.

예외 변환

• EntityManager는 순수한 JPA 기술이고 ,스프링과는 관계가 없기 때문에 엔티티 매니저는 예외가 발생하면 JPA 관련 예외를 발생시킨다.
• JPA는 PersistenceException 과 그 하위 예외 IllegalStateException, IllegalArgumentException 을 발생시킨다.
  • 이렇게 되면 런타임 에러인 해당 에러는 서비스 계층까지 던져져 서비스 계층이 JPA기술에 의존적이게 된다.

@Repository

• @Repository Annotation은 해당 클래스가 컴포넌트 스캔의 대상이라는 선언 기능과 예외 변환 AOP의 적용 대상이 되는 기능이 있다.

✔️ 스프링 데이터 JPA

이론

• 스프링 데이터 JPA는 JPA를 편리하게 사용할 수 있도록 도와주는 라이브러리이다.
• 대표 기능
  • 공통 인터페이스 기능
  • 쿼리 메서드 기능

적용 - JpaRepository Interface

사용법

• JpaRepository 인터페이스를 상속받고, 제네릭에 관리할 <엔티티, 엔티티ID>를 준다.
  • 그러면 JpaRepository가 제공하는 기본 CRUD 기능을 모두 사용할 수 있다.
  • 스프링 데이터 JPA가 프록시 기술을 사용해서 해당 인터페이스의 구현체를 만들고 구현체의 인스턴스를 만들어서 스프링 빈으로 등록한다.
    • 따라서 개발자는 구현 클래스 없이 인터페이스만으로 CRUD 기능을 사용할 수 있다.

쿼리 메서드 기능

• 기본 CRUD 외에 메서드를 사용하고 싶다면 쿼리 메서드 기능을 사용하면 된다.
• 스프링 데이터 JPA는 인터페이스에 메서드만 적어두면 메서드 이름을 분석해서 쿼리를 자동으로 만들고 실행해주는 기능을 제공한다. 쿼리 메서드 필터 조건 공식 문서
  

JPQL 직접 작성

• 메서드 이름이 너무 복잡하고 긴 경우 @Query 를 사용해 직접 JPQL을 작성할 수 있다.
• 스프링 데이터 JPA는 JPQL 뿐만 아니라 SQL로도 직접 작성할 수 있도록 해준다.

public interface SpringDataJpaItemRepository extends JpaRepository<Item, Long> {

    List<Item> findByItemNameLike(String itemName);
    List<Item> findByPriceLessThanEqual(Integer price);

    //쿼리 메서드
    List<Item> findByItemNameLikeAndPriceLessThanEqual(String itemName, Integer price);

    //쿼리 직접 실행
    @Query("select i from Item i where i.itemName like :itemName and i.price <= :price")
    List<Item> findItems(@Param("itemName") String itemName,@Param("price") Integer price);
}

주의점과 플로우

의존관계와 구조

• ItemService는 ItemRepository에 의존하기 때문에 ItemService에서 SpringDataJpaItemRepository 를 그대로 사용할 수 없다.
  • JpaItemRepositoryV2를 만들어 ItemRepository 와 SpringDataJpaItemRepository 사이를 맞추기 위한 어댑터처럼 사용한다.

클래스 의존관계

런타임 객체 의존관계

예외 변환

• 스프링 데이터 JPA도 스프링 예외 추상화를 지원한다.
• 스프링 데이터 JPA가 만들어주는 프록시에서 이미 예외 변환을 처리하기 때문에 @Repository 에 관계없이 예외가 변환된다.

Querydsl

설정

• dependecy 추가, build-clean 추가
• Querydsl 사용을 위해서는 Q클래스를 생성해야한다.

빌드 툴에 따른 Q클래스 생성 방법

1. Gradle
   1. Gradle -> Tasks -> build -> clean
   2. Gradle -> Tasks -> other -> compileJava
   • build → generated 하위 패키지에 확인해보면 QItem이 생성되어 있어야 한다
   • Q타입 삭제를 위해서는 gradle clean을 수행하면 build 폴더 자체가 삭제된다.
2. IntelliJ IDEA
   1. Build → Build Project 또는 Build → Rebuild 또는 main() 실행 또는 테스트 실행
   • src → main → generated 하위에 QItem 생성

※ Q타입은 컴파일 시점에 자동 생성되므로 버전관리에 포함하지 않는 것이 좋다. src/main/generated 를 포함하지 않는다.

적용

QueryDslRepository 코드

@Repository
@Transactional
public class JpaItemRepositoryV3 implements ItemRepository {

    private final EntityManager em;
    private final JPAQueryFactory query;

    public JpaItemRepositoryV3(EntityManager em) {
        this.em = em;
        this.query = new JPAQueryFactory(em);
    }

    @Override
    public List<Item> findAll(ItemSearchCond cond) {
        String itemName = cond.getItemName();
        Integer maxPrice = cond.getMaxPrice();

        return query.select(item)
                .from(item)
                .where(likeItemName(itemName), maxPrice(maxPrice))
                .fetch();
    }

    private BooleanExpression maxPrice(Integer maxPrice) {
        if(maxPrice != null){
            return item.price.loe(maxPrice);
        }
        return null;
    }

    private BooleanExpression likeItemName(String itemName) {
        if (StringUtils.hasText(itemName)){
            return item.itemName.like("%" + itemName + "%");
        }
        return null;
    }
}

• JpaQueryFactory를 주입받아야 하며 JpaQueryFactory는 JPA 쿼리인 JPQL을 만들기 때문에 EntityManager가 필요하다.
• JPAQueryFactory를 스프링 빈으로 등록해서 사용해도 된다.

예외 변환

• Querydsl 은 별도의 스프링 예외 추상화를 지원하지 않는다. 대신에 JPA에서 학습한 것처럼 @Repository 에서 스프링 예외 추상화를 처리해준다.

장점

• 오타가 있어도 컴파일 시점에 오류를 막을 수 있다.
• 메서드 추출을 통해서 코드를 재사용할 수 있다.

✔️ 데이터 접근 기술 활용 방안 - 트레이드 오프

어댑터 도입, 구조 유지 - 현재 상태

클래스 의존관계

런타임 객체 의존관계

• 현재의 구조는 JpaItemRepositoryV2가 중간에서 어댑터 역할을 해준 덕분에 ItemService가 사용하는 ItemRepository 인터페이스를 그대로 유지할 수 있고 ItemService의 코드를 변경하지 않아도 되는 장점이 있다.
  • DI, OCP 원칙을 지킬 수 있다.
• 하지만 구조가 복잡하고 어댑터 코드와 실제 코드까지 함께 유지보수 해야 하는 어려움이 발생한다.

실용적인 구조

• ItemRepositoryV2 : 스프링 데이터 JPA의 기능을 제공하는 리포지토리

  public interface ItemRepositoryV2 extends JpaRepository<Item, Long> {
  }

• ItemQueryRepositoryV2 : Querydsl을 사용해서 복잡한 쿼리 기능을 제공하는 리포지토리

  @Repository
  public class ItemQueryRepositoryV2 {
      private final JPAQueryFactory query;
  
      public ItemQueryRepositoryV2(EntityManager em) {
          this.query = new JPAQueryFactory(em);
      }
  
      public List<Item> findAll(ItemSearchCond cond) {
          String itemName = cond.getItemName();
          Integer maxPrice = cond.getMaxPrice();
  
          return query.select(item)
                  .from(item)
                  .where(likeItemName(itemName), maxPrice(maxPrice))
                  .fetch();
      }
  
      private BooleanExpression maxPrice(Integer maxPrice) {
          if(maxPrice != null){
              return item.price.loe(maxPrice);
          }
          return null;
      }
  
      private BooleanExpression likeItemName(String itemName) {
          if (StringUtils.hasText(itemName)){
              return item.itemName.like("%" + itemName + "%");
          }
          return null;
      }
  }

• Service 계층에서 두가지 레포지토리를 모두 주입받는다.
  • 두가지 모두 스프링 빈으로 등록
  • ItemRepositoryV2는 스프링에서 구현체를 생성해 인스턴스를 스프링 빈에 등록해준다.

트레이드 오프

• DI, OCP를 지키기 위해 어댑터를 도입하고, 더 많은 코드를 유지한다.
• 어댑터를 제거하고 구조를 단순하게 가져가지만, DI, OCP를 포기하고 ItemService 코드를 직접 변경한다.

→ 구조의 안정성 VS 단순한 구조

• 추상화도 비용이 든다. - 유지 보수 관점에서의 비용
  • 이 추상화 비용을 넘어설 만큼 효과가 있을 때 추상화를 도입하는 것이 실용적이다.
• 현재 상황에 맞는 선택을 하자 → 프로젝트 규모와 변동성에 따라 선택

다양한 데이터 접근 기술 조합

• 실무에서 95% 정도는 JPA, 스프링 데이터 JPA, Querydsl 등으로 해결하고, 나머지 5%는 SQL을 직접 사용해야 하니 JdbcTemplate이나 MyBatis로 해결한다.

트랜잭션 매니저 선택

• JPA, 스프링 데이터 JPA, Querydsl은 모두 JPA 기술을 사용하는 것이기 때문에 JpaTransactionManager 를 선택하면 된다. 해당 기술을 사용하면 스프링 부트는 자동으로 해당 매니저를 스프링 빈에 등록한다.
• 그런데 JdbcTemplate, MyBatis 와 같은 기술들은 내부에서 JDBC를 직접 사용하기 때문에 DataSourceTransactionManager 를 사용한다.
• 이렇게 트랜잭션 매니저가 달라지는 문제가 있지만 **JpaTransactionManager 는 DataSourceTransactionManager 가 제공하는 기능을 대부분 제공한다.**
  • JPA라는 기술도 결국 내부에서는 DataSource와 JDBC 커넥션을 사용하기 때문이다.

주의점

• JPA와 JdbcTemplate을 함께 사용할 경우 JPA의 플러시 타이밍에 주의해야 한다.
  • JPA 강의에서 다룰 예정

✔️ 스프링 트랜잭션

트랜잭션의 이해

• DB 1편 트랜잭션 참고

트랜잭션 적용 확인

• 코드

  @Slf4j
  @SpringBootTest
  public class TxBasicTest {
  
      @Autowired BasicService basicService;
  
      @Test
      void proxyCheck(){
          log.info("aop class={}", basicService.getClass());
          Assertions.assertThat(AopUtils.isAopProxy(basicService)).isTrue();
      }
  
      @Test
      void txTest(){
          basicService.tx();
          basicService.nonTx();
      }
  
      @TestConfiguration
      static class TxApplyBasicConfig{
  
          @Bean
          BasicService basicService(){
              return new BasicService();
          }
      }
  
      @Slf4j
      static class BasicService{
  
          @Transactional
          void tx(){
              log.info("call tx");
              boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
              log.info("tx active={}", txActive);
          }
  
          void nonTx(){
              log.info("call nonTx");
              boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
              log.info("tx active={}", txActive);
          }
  
      }
  }

• AopUtils.isAopProxy() : 선언적 트랜잭션 방식에서 스프링 트랜잭션은 AOP를 기반으로 동작한다.

스프링 컨테이너에 트랜잭션 프록시 등록

• @Transactional 을 클래스나 메서드에 붙이면 해당 객체는 트랜잭션 AOP의 대상이되고, 클래스내에 하나의 @Transactional 이라도 있으면 스프링 빈에 서비스 객체 대신에 서비스 프록시 객체가 등록된다.
  • 주입 받을 때 또한 프록시 객체가 주입된다.
• 프록시는 BasicService 를 상속해서 만들어지기 때문에 다형성을 활용할 수 있다.
  • 따라서 BasicService 대신에 프록시인 BasicService$$CGLIB 을 주입할 수 있다.
    • 부모는 자식을 품을 수 있다.

트랜잭션 프록시 동작 방식

• basicService.tx 호출
  • 프록시의 tx()가 호출된다. 프록시는 tx() 메서드가 트랜잭션을 사용할 수 있는지 확인해본다.
  • 트랜잭션을 시작한 다음 실제 basicService.tx() 를 호출한다.
  • 그리고 실제 basicService.tx()의 호출이 끝나서 프록시로 제어가 돌아오면 프록시는 트랜잭션을 커밋하거나 롤백해서 트랜잭션을 종료한다.
• nonTx 호출
  • 트랜잭션 대상이 아니라면 바로 basicService.nonTx() 를 참조해서 호출하고 종료한다.
• TransactionSynchronizationManager.isActualTransactionActive()
  • 현재 쓰레드에 트랜잭션이 적용되어 있는지 확인
  • Boolean값 반환

트랜잭션 적용 위치 - 우선순위

• 스프링에서 우선순위는 항상 더 구체적이고 자세한 것이 높은 우선순위를 가진다.

인터페이스에 @Transactional 적용

• 우선 순위
  1. 클래스의 메서드
  2. 클래스의 타입
  3. 인터페이스의 메서드
  4. 인터페이스의 타입
• 그런데 인터페이스에 @Transactional 을 사용하는 것은 스프링 공식 메뉴얼에서 권장하지 않는 방법이다.
  • AOP를 적용하는 방식에 따라서 인터페이스에 애노테이션을 두면 AOP가 적용 되지 않는 경우도 있기 때문이다.

트랜잭션 AOP 주의 사항 - 프록시 내부 호출

• 트랜잭션 AOP는 기본적으로 프록시 방식의 AOP를 사용한다.
• @Transactional 을 적용하면 프록시 객체가 요청을 먼저 받아서 트랜잭션을 처리하고 실제 객체를 호출해준다.
  • 따라서 트랜잭션을 호출하려면 항상 프록시를 통해서 대상 객체를 호출해야 한다.
• 만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 트랜잭션도 적용되지 않는다.

• 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생한다.

프록시와 내부 호출

• 코드

  @Slf4j
  @SpringBootTest
  public class InternalCallV1Test {
      @Autowired
      CallService callService;
      @Test
      void printProxy() {
          log.info("callService class={}", callService.getClass());
      }
      @Test
      void internalCall() {
          callService.internal();
      }
      @Test
      void externalCall() {
          callService.external();
      }
      @TestConfiguration
      static class InternalCallV1Config {
          @Bean
          CallService callService() {
              return new CallService();
          }
      }
      @Slf4j
      static class CallService {
          public void external() {
              log.info("call external");
              printTxInfo();
              internal();
          }
          @Transactional
          public void internal() {
              log.info("call internal");
              printTxInfo();
          }
          private void printTxInfo() {
              boolean txActive =
                      TransactionSynchronizationManager.isActualTransactionActive();
              log.info("tx active={}", txActive);
          }
      }
  }

1. 클라이언트인 테스트 코드는 트랜잭션 프록시에서 external()을 호출한다.
2. callService의 트랜잭션 프록시가 호출된다.
3. external() 메서드에는 @Transactional이 없다.
4. 그러므로 실제 객체의 실제 callService의 external()이 호출된다.
5. external()은 내부에서 internal() 메서드를 호출한다. → 여기서 문제가 발생한다.

문제 원인

• 자바 언어에서 메서드 앞에 별도의 참조가 없으면 this 라는 뜻으로 자기 자신의 인스턴스를 가리킨다.
• this.internal() 에서 this 는 자기 자신, 실제 대상 객체의 인스터스를 뜻하므로 이러한 내부 호출은 프록시를 거치지 않는다.
  • 따라서 트랜잭션을 적용할 수 없다.

가장 간단한 해결 방안 - 클래스 분리

• 코드

  @Slf4j
  @SpringBootTest
  public class InternalCallV2Test {
  
      @Autowired CallService callService;
  
      @Test
      void externalCallV2(){
          callService.external();
      }
  
      @TestConfiguration
      static class InternalCallV1Config{
          @Bean
          CallService callService(){
              return new CallService(internalService());
          }
  
          @Bean
          InternalService internalService(){
              return new InternalService();
          }
      }
  
      @RequiredArgsConstructor
      static class CallService{
  
          private final InternalService internalService;
  
          public void external(){
              log.info("call external");
              printTxInfo();
              internalService.internal();
          }
  
          private void printTxInfo(){
              boolean active = TransactionSynchronizationManager.isActualTransactionActive();
              log.info("tx active={}", active);
              boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
              log.info("readOnly={}", readOnly);
          }
      }
  
      @Slf4j
      static class InternalService{
  
          @Transactional
          public void internal(){
              log.info("call internal");
              printTxInfo();
          }
  
          private void printTxInfo(){
              boolean active = TransactionSynchronizationManager.isActualTransactionActive();
              log.info("tx active={}", active);
              boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
              log.info("readOnly={}", readOnly);
          }
  
      }
  }

Public 메서드

• 스프링의 트랜잭션 AOP 기능은 public 메서드에만 트랜잭션을 적용하도록 기본 설정이 되어있다.
  • protected, private, package-visible 에는 트랜잭션이 적용되지 않는다.

트랜잭션 AOP 주의 사항 - 초기화 시점

• 스프링 초기화 시점에는 트랜잭션 AOP가 적용되지 않을 수 있다.

@PostConstruct
@Transactional
public void initV1(){
    boolean active = TransactionSynchronizationManager.isActualTransactionActive();
    log.info("Hello init @PostConstruct tx active={}", active);
}

• 다음과 같이 선언 시 초기화 코드가 먼저 호출 되고 그 다음에 트랜잭션 AOP가 적용되기 때문에 해당 메서드에서 트랜잭션을 흭득할 수 없다.

대안

@EventListener(ApplicationReadyEvent.class)
@Transactional
public void initV2(){
    boolean active = TransactionSynchronizationManager.isActualTransactionActive();
    log.info("Hello init ApplicationReadyEvent tx active={}", active);
}

• 다음과 같이 선언 시 트랜잭션 AOP를 포함한 스프링이 컨테이너가 완전히 생성되고 난 다음에 이벤트가 붙은 메서드를 호출한다.

트랜잭션 옵션

• PDF 참고

예외와 트랜잭션 커밋, 롤백

• 예외가 발생했는데 내부에서 예외를 처리하지 못하고 트랜잭션 범위(@Transactional이 적용된 AOP) 밖으로 예외를 던지면?

  - **언체크 예외는 트랜잭션을 롤백한다.** - **체크 예외는 트랜잭션을 커밋한다.** - **이 정책이 디폴트이고 이 정책을 따르고 싶지 않다면 `rollbackFor` 이라는 옵션을 사용해서 체크 예외도 롤백시킬 수 있다.**

체크, 언체크에 따른 커밋, 롤백 이유

• 체크 예외는 비즈니스상 의미가 있을 때 사용할 것이라고 생각하기 때문에 커밋한다. (서비스 계층이나 컨트롤러 계층에서 예외를 잡아서 비즈니스 로직 처리)
• 언체크 예외는 복구 불가능한 예외이기 때문에 롤백한다.
• OrderService 코드

  @Slf4j
  @Service
  @RequiredArgsConstructor
  public class OrderService {
  
      private final OrderRepository orderRepository;
  
      @Transactional
      public void order(Order order) throws NotEnoughMoneyException {
          log.info("order 호출");
          orderRepository.save(order);
  
          log.info("결제 프로세스 호출");
          if (order.getUsername().equals("예외")){
              log.info("시스템 예외");
              throw new RuntimeException();
          } else if (order.getUsername().equals("잔고부족")){
              log.info("비즈니스 예외");
              order.setPayStatus("대기");
              throw new NotEnoughMoneyException("잔고가 부족합니다");
          } else{
              log.info("정상 승인");
              order.setPayStatus("완료");
          }
          log.info("결제 프로세스 완료");
      }
  }

• OrderServiceTest 코드

  @Slf4j
  @SpringBootTest
  public class OrderServiceTest {
  
      @Autowired
      OrderService orderService;
      @Autowired
      OrderRepository orderRepository;
  
      @Test
      void complete() throws NotEnoughMoneyException {
          Order order = new Order();
          order.setUsername("정상");
  
          orderService.order(order);
  
          Order findOrder = orderRepository.findById(order.getId()).get();
          Assertions.assertThat(findOrder.getPayStatus()).isEqualTo("완료");
      }
      @Test
      void runtimeException() {
          Order order = new Order();
          order.setUsername("예외");
  
          Assertions.assertThatThrownBy(() -> orderService.order(order))
                  .isInstanceOf(RuntimeException.class);
  
          Optional<Order> byId = orderRepository.findById(order.getId());
          Assertions.assertThat(byId.isEmpty()).isTrue();
      }
      @Test
      void bizException(){
          Order order = new Order();
          order.setUsername("잔고부족");
  
          try{
              orderService.order(order);
              fail("잔고 부족 예외가 발생해야 합니다");
          }catch (NotEnoughMoneyException e){
              log.info("고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내");
          }
  
          Order findOrder = orderRepository.findById(order.getId()).get();
          Assertions.assertThat(findOrder.getPayStatus()).isEqualTo("대기");
      }
  }

✔️ 스프링 트랜잭션 전파 이론

• 트랜잭션이 둘 이상 있을 때 어떻게 동작하는지 알아본다.

별개의 트랜잭션 2번 사용

• 코드

  @Test
      void double_commit(){
          log.info("트랜잭션1 시작");
          TransactionStatus status1 = txManager.getTransaction(new DefaultTransactionAttribute());
          log.info("트랜잭션1 커밋");
          txManager.commit(status1);
  
          log.info("트랜잭션2 시작");
          TransactionStatus status2 = txManager.getTransaction(new DefaultTransactionAttribute());
          log.info("트랜잭션2 커밋");
          txManager.commit(status2);
      }

• 로그를 보면 트랜잭션1과 트랜잭션1는 같은 conn0 커넥션을 사용중이다.
  • 이 것은 Hikari 커넥션 풀을 사용하기 때문이다.
• 이 둘을 구분하는 방법이 있다.
  • 히카리 커넥션 풀에서 커넥션을 흭득하면 실제 커넥션을 그대로 반환하는 것이 아니라 내부 관리를 위해 히카리 프록시 커넥션이라는 객체를 생성해서 반환한다.
  • 이 객체의 주소를 확인하면 커넥션 풀에서 흭득한 커넥션을 구분할 수 있다.

트랜잭션 전파 이론

• 외부 트랜잭션이 수행 중인데, 내부 트랜잭션이 추가로 수행될 경우
  • 스프링이 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어준다.
  • 내부 트랜잭션이 외부 트랜잭션에 참여하는 것이다.

물리 트랜잭션과 논리 트랜잭션

• 논리 트랜잭션은 하나의 물리 트랜잭션으로 묶인다.
• 물리 트랜잭션은 실제 데이터베이스에 적용되는 트랜잭션을 뜻한다.
• 논리 트랜잭션은 트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위이다.

→ 트랜잭션이 사용 중일 때 또 다른 트랜잭션이 내부에 사용되면 여러가지 복잡한 상황이 발생한다. 그렇기 때문에 다음과 같은 단순한 원칙을 만들기 위해 물리, 논리 트랜잭션이라는 개념을 도입하는 것이다.

⚠️ 원칙

• **모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다.
• 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다.**

전파 예제, 플로우

• 코드

  @Test
      void inner_commit(){
          log.info("외부 트랜잭션 시작");
          TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
          log.info("outer.isNewTransaction()={}", outer.isNewTransaction());
  
          log.info("내부 트랜잭션 시작");
          TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
          log.info("inner.isNewTransaction()={}", inner.isNewTransaction());
          log.info("내부 트랜잭션 커밋");
          txManager.commit(inner);
  
          log.info("외부 트랜잭션 커밋");
          txManager.commit(outer);
      }

플로우

• 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부가 담겨 있다.
  • isNewTransaction 을 통해 신규 트랜잭션 여부를 확인할 수 이따.
• 트랜잭션 매니저는 트랜잭션을 시작할 때 항상 트랜잭션 동기화 매니저를 통해 기존 트랜잭션이 존재하는지 확인한다.
• 내부 트랜잭션 커밋 시 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다.

전파 - 외부 롤백

• 내부 트랜잭션이 커밋되어도 해당 트랜잭션은 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다. 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버린다.

전파 - 내부 롤백

• 내부 트랜잭션이 롤백을 했지만, 내부 트랜잭션은 물리 트랜잭션에 영향을 주지 않는다.
  • 물리 트랜잭션에 영향을 주지 않는 대신 커넥션 동기화 매니저에 rollbackOnly=true 라는 표시를 해둔다.
• 외부 트랜잭션을 커밋하는 시점에 트랜잭션 동기화 매니저에 rollbackOnly 가 있는지 확인한다.
  • 해당 표시가 있으면 물리 트랜잭션을 롤백하고 UnexpectedRollbackException 런타임 예외를 던진다.

전파 - REQUIRES_NEW

• 외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법이다.
• 내부 트랜잭션에 해당 옵션을 설정하면 conn0 이 아닌 conn1, 즉 다른 커넥션을 사용하여 트랜잭션을 시작한다.
  • isNewTransaction()=true 가 된다.

다양한 전파 옵션

• isolation, timeout, readOnly 는 트랜잭션이 처음 시작될 때만 적용된다.
  • 트랜잭션에 참여하는 경우에는 적용되지 않는다.
• 실무에서는 대부분 REQUIRED - Default 옵션을 사용하고 아주 가끔 REQUIRES_NEW 를 사용하고 나머지는 거의 사용하지 않는다.
  • 나머지 옵션은 PDF 참고

✔️ 전파 활용

코드

@Slf4j
@SpringBootTest
class MemberServiceTest {

    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository;
    @Autowired LogRepository logRepository;

    /**
     * MemberService    @Transactional:OFF
     * MemberRepository @Transactional:ON
     * MemberRepository @Transactional:OFF
     */

    @Test
    void outerTxOff_success(){
        String username = "outerTxOff_success";

        memberService.joinV1(username);

        Assertions.assertTrue(memberRepository.find(username).isPresent());
        Assertions.assertTrue(logRepository.find(username).isPresent());
    }

    /**
     * MemberService    @Transactional:OFF
     * MemberRepository @Transactional:ON
     * MemberRepository @Transactional:ON Exception
     */

    @Test
    void outerTxOff_fail(){
        String username = "로그예외_outerTxOff_fail";
        assertThatThrownBy(() -> memberService.joinV1(username))
                .isInstanceOf(RuntimeException.class);

        Assertions.assertTrue(memberRepository.find(username).isPresent());
        Assertions.assertTrue(logRepository.find(username).isEmpty());
    }

    /**
     * MemberService    @Transactional:ON
     * MemberRepository @Transactional:OFF
     * MemberRepository @Transactional:OFF
     */

    @Test
    void singleTx(){
        String username = "singleTx";
        memberService.joinV1(username);

        Assertions.assertTrue(memberRepository.find(username).isPresent());
        Assertions.assertTrue(logRepository.find(username).isPresent());
    }

    /**
     * MemberService    @Transactional:ON
     * MemberRepository @Transactional:ON
     * MemberRepository @Transactional:ON
     */

    @Test
    void outerTxOn_success(){
        String username = "outerTxOn_success";
        memberService.joinV1(username);

        Assertions.assertTrue(memberRepository.find(username).isPresent());
        Assertions.assertTrue(logRepository.find(username).isPresent());
    }

    /**
     * MemberService    @Transactional:ON
     * MemberRepository @Transactional:ON
     * MemberRepository @Transactional:ON Exception
     */

    @Test
    void outerTxOn_fail(){
        String username = "로그예외_outerTxOn_fail";
        assertThatThrownBy(() -> memberService.joinV1(username))
                .isInstanceOf(RuntimeException.class);

        Assertions.assertTrue(memberRepository.find(username).isEmpty());
        Assertions.assertTrue(logRepository.find(username).isEmpty());
    }

    /**
     * MemberService    @Transactional:ON
     * MemberRepository @Transactional:ON
     * MemberRepository @Transactional:ON Exception
     */

    @Test
    void recoverException_fail(){
        String username = "로그예외_recoverException_fail";
        assertThatThrownBy(() -> memberService.joinV2(username))
                .isInstanceOf(UnexpectedRollbackException.class);

        Assertions.assertTrue(memberRepository.find(username).isEmpty());
        Assertions.assertTrue(logRepository.find(username).isEmpty());
    }

    /**
     * MemberService    @Transactional:ON
     * MemberRepository @Transactional:ON
     * MemberRepository @Transactional:ON(REQUIRES_NEW) Exception
     */

    @Test
    void recoverException_success(){
        String username = "로그예외_recoverException_success";
        memberService.joinV2(username);

        Assertions.assertTrue(memberRepository.find(username).isPresent());
        Assertions.assertTrue(logRepository.find(username).isEmpty());
    }

}

outerTxOn_fail

• 이 경우 트랜잭션C에서 rollbackOnly를 설정하지만 트랜잭션A까지 예외가 잡히지 않고 던져졌기 때문에 <트랜잭션 매니저에 커밋을 요청한 후 rollBackOnly를 확인 후 롤백을 실행하는 것>이 아니라 트랜잭션 매니저에 롤백을 요청한다.
  • 이 경우에는 rollBackOnly 설정을 참고하지 않는다.

recoverException_fail

• 이 경우 MemberService에서 예외를 처리하기 때문에 정상 흐름으로 돌아간다.
• 논리 트랜잭션A는 트랜잭션 매니저에 커밋을 요청하고 트랜잭션 매니저는 rollbackOnly 설정을 참고한다.
  • rollBackOnly가 True이기 때문에 롤백을 하고 UnexpectedRollbackException 을 클라이언트에게 던진다.

recoverException_success - REQUIRES_NEW

• 회원 가입을 시도한 로그를 남기는데 실패하더라도 회원 가입은 유지되어야 할 경우

• Propagation.REQUIRES_NEW를 설정할 경우 트랜잭션이 기존 물리 트랜잭션에 참여하는 것이 아니라 신규 물리 트랜잭션이 시작된다.
  • 그렇기 때문에 트랜잭션C에서 롤백이 되면 해당 트랜잭션은 트랙잭션A와는 별개로 종료된다.
  • 트랜잭션은 분리시켰지만 발생한 런타임예외는 밖으로 던져진다.
    • 하지만 MemberService에서 해당 예외를 잡기 때문에 정상흐름으로 돌아온다.