555 SQL Error: 1054, SQLState: 42S22

Wed, 05 Jul 2023 16:05:46 GMT

SQL문에서 사용한 컬럼이 DB에 존재하지 않을 때 발생하는 에러

서버에 배포한 후 Entity를 변경이 있으면 꼭 ALTER TABLE 해주기!!
스네이크 케이스 주의...
- DB에는 스네이크 케이스로 작성해야되는데 카멜 케이스로 작성해서 한 시간...ㅎ

SQL Error: 1451, SQLState: 23000

Wed, 05 Jul 2023 14:35:12 GMT

회원 탈퇴 시 발생한 에러

User Entity 상태 업데이트 시, User Entity에 ManyToOne(One이 User)으로 매핑되어 있는 객체들을 처리하는 규칙이 정해져 있지 않아 발생하는 에러이다.

이런 경우 User 객체를 삭제하기 전에 먼저 관련 객체들을 모두 삭제해야 한다.

  @Override
  public void withdrawalUser(User user) {
      try {
          userLectureRepository.deleteAllByUser(user);            |
          userNotificationRepository.deleteAllByUser(user);        > 추가
          tokenRepository.deleteAllByUser(user);                  |

          userRepository.deleteById(user.getId());
      } catch (Exception e){
          throw new BaseException(Code.WITHDRAWAL_FAILED);
      }
  }

[리눅스] 서버 로그 관리

Wed, 05 Jul 2023 14:28:08 GMT

스프링 로그

스프링에서는 로그를 관리하기 위해서 application.properties 와 logback-spring.xml 파일을 사용한다. 전자의 경우 로그 레벨 설정과 같은 간단한 설정밖에 하지 못하기 때문에 특정 비즈니스 로직별, 일자별과 같이 자세한 설정을 위해서는 logback-spring.xml을 사용해야 한다.

Logback

Logback은 log4j를 발전시킨 Logging Framework로 Spring Boot는 spring-boot-starter-web -> spring-boot-starter-logging에 logback 구현체가 포함되어 있다. 그래서 의존성을 따로 추가하지 않아도 logback이 기본 로깅 구현체로 자동 적용된다.

이렇게 적용된 로깅 구현체는 SLF4J(Simple Logging Framework for JAVA : interface)와 compile시에 바인딩된다.

Log Level

로그 레벨은 5가지로 구성되며 오른쪽으로 갈수록 단계가 높아진다.

Trace ➡ Debug ➡ Info ➡ Warn ➡ Error

리눅스 서버 로그 관리

먼저 로그 관리의 기본인 로테이션이라는 용어부터 정리해보자

로테이션

로그 로테이션의 경우, 시스템이나 애플리케이션에서 생성되는 로그 파일이 일정 크기에 도달하거나 일정 시간이 지나면 새로운 로그 파일을 생성하고 오래된 로그 파일을 압축, 아카이빙, 또는 삭제하는 프로세스를 말합니다.
예를 들어, 로그 파일이 일주일마다 로테이션이 설정되어 있다면, 매주 새로운 로그 파일이 생성되고 이전 주의 로그 파일은 아카이빙되거나 삭제될 것이다. 이렇게 함으로써 로그 파일이 무한정 커지는 것을 방지하고, 디스크 공간을 효율적으로 활용하며, 로그 데이터를 쉽게 관리할 수 있다.

현재 나의 EC2 서버는 Nginx, Docker(WAS:Tomcat)으로 이루어져 있다.

Nginx

`/etc/nginx/nginx.conf`

로그 파일의 저장 경로와 로그 출력 형식을 지정할 수 있다.
로그 출력 형식 Default
```
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
```
192.0.2.1 - john [10/Jul/2023:14:02:39 +0900] "GET /index.html HTTP/1.1" 200 555 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36" "-"
- $remote_addr: 클라이언트의 IP 주소를 나타낸다.
- $remote_user: 인증된 사용자의 이름을 나타낸다.
- $time_local: 로컬 시간을 나타냅니다. 이는 접속 시간을 나타낸다.
- $request: 클라이언트의 원래 요청 문자열을 나타낸다. 이는 사용자가 요청한 URL 및 HTTP 메서드(GET, POST 등)을 나타낸다.
- $status: 요청에 대한 응답의 HTTP 상태 코드를 나타낸다.
- $body_bytes_sent: 응답 본문의 바이트 크기를 나타낸다.
- $http_referer: 클라이언트 HTTP 헤더의 Referer 필드를 나타낸다. 이는 사용자가 해당 요청을 하기 이전에 방문했던 웹페이지의 URL을 나타낸다.
- $http_user_agent: 클라이언트 HTTP 헤더의 User-Agent 필드를 나타낸다. 이는 클라이언트의 브라우저, 운영 체제 등의 정보를 나타낸다.
- $http_x_forwarded_for: 클라이언트 HTTP 헤더의 X-Forwarded-For 필드를 나타낸다. 이는 프록시나 로드 밸런서를 통해 서버에 도달한 요청의 경우, 원래 클라이언트의 IP 주소를 나타낸다.

`/etc/logroate.conf`

Linux 시스템에서 로그 파일 로테이션(자동 로그 관리)을 제어하는 설정 파일이다. 이 파일의 설정에 따라, 로그 파일의 크기가 일정 크기에 도달하거나 일정 시간이 경과하면 새로운 로그 파일을 생성하고, 오래된 로그 파일을 삭제하거나 압축하는 작업을 수행한다.
/etc/logrotate.conf 설정 파일에는 전역 설정을 포함하고, /etc/logrotate.d/ 디렉토리에는 개별 서비스(예: apache, nginx 등)에 대한 로그 로테이션 설정 파일이 위치해 있다.
/etc/logroate.conf/nginx
- Default 값
```
/var/log/nginx/*.log {
create 0640 nginx root
daily
rotate 10
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
  /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
endscript
}
```
  /var/log/nginx/*.log { ... }: 이 설정이 적용될 로그 파일을 지정합니다./var/log/nginx/ 디렉토리 내의 모든 .log 파일에 이 설정이 적용됩니다.
  
  create 0640 nginx root: 로그 파일을 로테이션한 후 새 로그 파일을 생성합니다. 생성될 파일의 권한은 0640이며, 소유자는 'nginx', 그룹은 'root'입니다.
  
  daily: 로그 파일을 매일 로테이션합니다.
  
  rotate 10: 로그 파일을 최대 10개까지 유지합니다. 10개가 넘으면 가장 오래된 로그 파일부터 삭제됩니다.
  
  missingok: 로그 파일이 없을 경우 에러를 무시하고 넘어갑니다.
  
  notifempty: 로그 파일이 비어있는 경우 로테이션하지 않습니다.
  
  compress: 로테이션된 로그 파일을 gzip으로 압축합니다.
  
  delaycompress: 로테이션된 이전 로그 파일의 압축을 지연합니다. 이는 compress 옵션과 함께 사용될 때 유용하며, 프로그램이 로그 파일을 쓰는 중에 발생하는 에러를 방지해줍니다.
  
  sharedscripts: 로그 파일 모두에 대해 postrotate와 endscript 사이의 스크립트를 한 번만 실행합니다.
  
  postrotate ... endscript: 로그 파일을 로테이션한 후에 실행할 쉘 스크립트를 지정합니다. 이 스크립트는 Nginx에 USR1 시그널을 보내 로그 파일을 재오픈하라는 명령을 내립니다. 이는 Nginx가 현재 로그 파일을 계속 사용하는 것을 방지하며, 새로운 로그 파일에 로그를 기록하도록 합니다.

Logrotate

logrotate는 일반적으로 cron이라는 리눅스의 작업 스케줄러를 통해 주기적으로 실행된다.

리눅스 배포판에 따라 다르지만, 일반적으로 /etc/cron.daily 또는 /etc/cron.weekly 등의 디렉토리에 logrotate를 주기적으로 실행하는 스크립트가 포함되어 있다. 이 스크립트는 시스템이 부팅될 때 cron에 의해 자동으로 스케줄링된다.

logrotate -f와 같은 명령은 로그 파일의 로테이션을 즉시 강제로 실행할 때 사용되며, 일반적으로 디버깅이나 테스트, 또는 디스크 공간을 즉시 확보해야 할 경우에 사용된다.

DORO 운영 서버 수정사항

Sat, 24 Jun 2023 07:18:19 GMT

💠 OSIV 성능최적화

실시간 트래픽이 중요한 서비스가 아니고 DB 커넥션이 부족할 만큼 트래픽이 많지 않기 때문에 아직은 OSIV를 켜두는 것으로 결정
💠 Application Properties 분리

운영 서버 / 개발 서버
DDL: NONE / CREATE
DataSource: RDS / Local MySQL
SQL LOG: False / True
Log Level: INFO / DEBUG
💠 DB PK 테이블별 Auto Increment 적용
GeneratedValue 전략 설정
💠 시큐리티 컨텍스트 홀더 초기화 AOP 적용

적용 대상

Domain 패키지의 하위 패키지의 모든 *Api 클래스
ClearSecurityContext Annotation 적용 메서드

💠 보안 강화 - 해킹 시도 차단

WAF 도입
- https://techblog.woowahan.com/2699/
  💠 핀포인트 도입
  
  💠 API 성능 테스트 - 쿼리 최적화
  
  💠 테스트 코드 작성

💠 회원가입 시 학교, 학과 검색 선택

[EC2] Error: Request timed out

Sat, 10 Jun 2023 16:38:32 GMT

EC2에 올려놓은 서버에 Request가 보내지지 않는다...

에러 로그

Error: Request timed out
Error: getaddrinfo ENOTFOUND

체크 사항

로드 밸런서 ✔️
타겟 그룹 ✔️
EC2 ✔️
Route53 - 로드 밸런서 연결 ✔️
네트워크 구성(VPC) ✔️
Nginx ✔️
Docker network ✔️

AWS

AWS에서 사용 중인 서비스들의 상태를 확인해봤지만 모든 요소가 정상 입력 되어있다. 상태 또한 Healthy로 정상 작동 중임을 확인했다.

Nginx

이러한 에러가 났을 때 내가 가장 먼저 취하는 액션은 로그 확인, WARNING 로그 제거이다. WARNING으로 인해서 서버가 작동 되지않는 경우는 드물지만 눈에 거슬리는 로그를 제거함과 동시에 에러의 범위를 좁혀 나갈 수 있는 좋은 기회라고 생각하기 때문이다.

WARNING - 80포트가 이미 사용 중입니다
- Nginx의 포트 번호와 타겟 그룹의 포트 번호를 변경하는 방법도 있지만 80번 포트를 사용하는 것이 직관적이기 때문에 포트 번호 변경 없이, 기존에 80포트를 사용 중인 프로세스를 중단시킨 후 Nginx를 재시작했다 --> WARNING 해결
엑세스 로그와 에러 로그가 찍히지 않는다.
- Nginx는 별도의 설정을 하지 않는다면 nginx.conf.default 파일을 기본 설정으로 실행된다. default 파일의 기본값에서 로그를 저장하는 부분은 수정하지 않았기 때문에 로그가 정상적으로 작동하지 않을 이유가 없었고 로그가 저장되는 원리를 공부해 잘못된 명령어가 있는지 확인했지만 전혀 문제가 없었다.
  
  결국 nginx를 삭제 후 재설치했지만 Default 패키지들이 재설치 되지 않는 문제 발생했다. 기존의 설정 파일들이 남아있다면 패키지들이 설치되지 않을 가능성이 있어 모든 패키지를 삭제하고 메타데이터 또한 삭제 후 which 명령어 와 nginx -v 을 통해 남은 nginx 패키지가 있는지 확인 후 재설치를 진행했지만 여전히 파일이 생성되지 않았다.
- 주변 사람들에게 자문을 구해봤지만 원인을 찾지 못했고 구글링, ChatGpt로도 그 원인을 찾지 못했다. 결국 EC2 인스턴스 포맷을 진행했다.
- 엑세스 로그에 HealthChecker 로그가 계속해서 찍혀 정상적인 로그 확인에 어려움을 느낀 나는 이번 기회에 엑세스 로그를 정상적인 Https 요청 로그와 Http 리다이렉트 로그로 분리했고 에러 로그와 HealthChecker 로그 파일을 별도로 관리할 수 있도록 설정했다.

Docker

Nginx까지도 Request가 들어오지 못한다는 것을 확인했기에 도커에서 에러가 발생했을 가능성은 0에 가까웠지만 WARNING을 해결하기로 결정했다.

Docker network - Docker Container를 Build 할 때 Docker network Warning이 발생했다.network를 삭제하고 ReBuild 함으로써 Warning 해결

해결

종단간 테스트를 진행하고 모든 로그를 확인했음에도 원인을 찾지 못했다 EC2 내부 까지 Request가 도달하지 못한다는 사실은 확실했고, 에러의 원인을 찾지 못한 이유는 방대한 AWS 에코시스템 내부에 내가 인지하지 못한 네트워크 요소들이 있기 때문일 가능성이 크다고 생각했다.
여기서 발동한 승부욕..니가 이기나 내가 이기나 해보자라는 생각으로 AWS Document를 정독해나갔다. 네트워크 (VPC, 서브넷, 게이트웨이 등), 로드 밸런서, 타겟 그룹, 그리고 Route53을 읽어 나가던 중 도메인을 구매한 후 15일 내에 이메일을 통한 인증이 이루어지지 않으면 도메인 사용이 중지된다는 내용을 발견했다. 그 후 이메일 인증을 진행했더니 정상작동되었다...ㅎ

원래는 이 내용에 대해 도메인 페이지에서 경고 메시지를 띄워준다고 한다. 하지만 내가 수차례 확인한 도메인 페이지에는 경고 메시지가 뜨지 않았고 콘솔창에도 관련 내용이 전혀 표시되지 않았다. 심지어 호스팅 영역에서 레코드 테스트를 진행했을 때도 정상적으로 응답이 수신되었다. 알아보니 Route53에서 제공하는 레코드 테스트는 실제 DNS로 쿼리를 보내는 것이 아니라 호스팅 영역의 레코드 설정에 따라 응답할 뿐, 호스팅 영역이 현재 도메인의 트래픽을 라우팅하는 데 사용되고 있는지 여부와 관계없이 동일한 정보를 반환한다고 한다..

레코드 테스트 결과를 믿고 나와 같은 삽질을 하는 사람들이 없었으면...🤣

📂 스프링 DB 2

Sun, 04 Jun 2023 12:59:30 GMT

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

용어 정리

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 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 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 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 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 param = Map.of("id", id);

`BeanPropertyRowMapper`

private RowMapper 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번 실행하는 경우 데이터를 중복으로 인해 에러가 발생한다.

테스트의 중요 원칙

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

데이터 롤백

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

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 findById(Long id);
    List findAll(ItemSearchCond itemSearchCond);
}

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

XML 파일




    
        insert into item(item_name, price, quantity)
        values (#{itemName}, #{price}, #{quantity})
    

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

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 사용
```
  
```

원리

매퍼 구현체

매퍼 구현체는 예외 변환까지 처리해준다.
- 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 findById(Long id) {
        Item item = em.find(Item.class, id);
        return Optional.ofNullable(item);
    }

    @Override
    public List 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 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 {

    List findByItemNameLike(String itemName);
    List findByPriceLessThanEqual(Integer price);

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

    //쿼리 직접 실행
    @Query("select i from Item i where i.itemName like :itemName and i.price <= :price")
    List 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클래스 생성 방법

Gradle
1. Gradle -> Tasks -> build -> clean
2. Gradle -> Tasks -> other -> compileJava
- build → generated 하위 패키지에 확인해보면 QItem이 생성되어 있어야 한다
- Q타입 삭제를 위해서는 gradle clean을 수행하면 build 폴더 자체가 삭제된다.
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 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 {
  }
```

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

  @Repository
  public class ItemQueryRepositoryV2 {
      private final JPAQueryFactory query;

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

      public List 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);
          }
      }
  }

클라이언트인 테스트 코드는 트랜잭션 프록시에서 external()을 호출한다.
callService의 트랜잭션 프록시가 호출된다.
external() 메서드에는 @Transactional이 없다.
그러므로 실제 객체의 실제 callService의 external()이 호출된다.
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 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에서 해당 예외를 잡기 때문에 정상흐름으로 돌아온다.

스프링 배치와 스케줄러의 차이

Thu, 01 Jun 2023 00:57:24 GMT

✔️ 배치란?

사용자와의 상호작용 없이 여러 작업을 미리 정해진 순서에 따라 중단 없이 처리하는 것
배치의 특징
- 대용량 데이터
- 자동화
- 견고성: 잘못된 데이터를 충돌/중단 없이 처리할 수 있어야 합니다.
- 신뢰성: 로깅, 알림 등을 통해 무엇이 잘못되었는지를 추적할 수 있어야 합니다.
- 성능: 지정한 시간 안에 처리를 완료하거나 동시에 실행되는 다른 프로그램을 방해하지 않아야 합니다.

스프링 배치 구성

배치 플로우

읽기(read) : 데이터 저장소(일반적으로 데이터베이스)에서 특정 데이터 레코드를 읽습니다.
처리(processing) : 원하는 방식으로 데이터 가공/처리 합니다.
쓰기(write) : 수정된 데이터를 다시 저장소(데이터베이스)에 저장합니다.

Job과 Step은 1:M Step과 ItemReader, ItemProcessor, ItemWriter 1:1

JobInstance

JobInstance는 배치 처리에서 Job이 실행될 때 하나의 Job 실행 단위입니다. 각각의 JobInstance는 하나의 JobExecution을 갖는 것은 아닙니다. 오늘 Job이 실행 했는데 실패했다면 다음날 동일한 JobInstance를 가지고 또 실행합니다. Job 실행이 실패하면 JobInstance가 끝난것으로 간주하지 않기 때문입니다. 그렇다면 JobInstance는 어제 실패한 JobExecution과 오늘의 성공한 JobExecution 두 개를 가지게 됩니다. 즉 JobExecution 는 여러 개 가질 수 있습니다.

JobExecution

JobExecution은 JobIstance에 대한 한 번의 실행을 나타내는 객체입니다. JobExecution은 JobInstance, 배치 실행 상태, 시작 시간, 끝난 시간, 실패했을 때 메시지 등의 정보를 담고 있습니다.

JobParameters

JobParameters는 Job이 실행될 때 필요한 파라미터들은 Map 타입으로 지정하는 객체 입니다. JobParameters는 JobInstance를 구분하는 기준이 되기도 합니다. JobParameters와 JobInstance는 1:1 관계입니다.

Step

Step은 실직적인 배치 처리를 정의하고 제어 하는데 필요한 모든 정보가 있는 도메인 객체입니다. Job을 처리하는 실질적인 단위로 쓰입니다. 모든 Job에는 1개 이상의 Step이 있어야 합니다.

StepExecution

Job에 JobExecution Job실행 정보가 있다면 Step에는 StepExecution이라는 Step 실행 정보를 담는 객체가 있습니다.

JobRepository

JobRepository는 배치 처리 정보를 담고 있는 매커니즘입니다. 어떤 Job이 실행되었으면 몇 번 실행되었고 언제 끝났는지 등 배치 처리에 대한 메타데이터를 저장합니다.
예를들어 Job 하나가 실행되면 JobRepository에서는 배치 실행에 관련된 정보를 담고 있는 도메인 JobExecution을 생성합니다.
JobRepository는 Step의 실행 정보를 담고 있는 StepExecution도 저장소에 저장하여 전체 메타데이터를 저장/관리하는 역할을 수행합니다.

JobLauncher

JobLauncher는 Job. JobParamerters와 함께 배치를 실행하는 인터페이스입니다.

ItemReader

ItemReader는 Step의 대상이 되는 배치 데이터를 읽어오는 인터페이스입니다. File, Xml Db등 여러 타입의 데이터를 읽어올 수 있습니다.

ItemProcessor

ItemProcessor는 ItemReader로 읽어 온 배치 데이터를 변환하는 역할을 수행합니다. 이것을 분리하는 이유는 다음과 같습니다.
비즈니스 로직의 분리 : ItemWriter는 저장 수행하고, ItemProcessor는 로직 처리만 수행해 역할을 명확하게 분리합니다. 읽어온 배치 데이터와 씌여질 데이터의 타입이 다를 경우에 대응할 수 있기 때문입니다.

ItemWriter

ItemWriter는 배치 데이터를 저장합니다. 일반적으로 DB나 파일에 저장합니다.
ItemWriter도 ItemReader와 비슷한 방식을 구현합니다. 제네릭으로 원하는 타입을 받고 write() 메서드는 List를 사용해서 저장한 타입의 리스트를 매게변수로 받습니다.

✔️ 스프링 배치를 이용한 휴먼 계정 처리

@Configuration
@RequiredArgsConstructor
@Slf4j
public class InactiveUserJobConfiguration {

    private final UserRepository userRepository;
    private final StepBuilderFactory stepBuilderFactory;
    private final JobBuilderFactory jobBuilderFactory;

    @Bean
    public Job inactiveUserJob(JobBuilderFactory jobBuilderFactory, Step inactiveJobStep) {
        return jobBuilderFactory.get("inactiveUserJob")
            .preventRestart()
            .incrementer(new RunIdIncrementer())
            .start(inactiveJobStep)
            .build();
    }

    @Bean
    public Step inactiveJobStep(StepBuilderFactory stepBuilderFactory) {
        return stepBuilderFactory.get("inactiveUserStep")
            . chunk(10)
            .reader(inactiveUserReader())
            .processor(inactiveUserProcessor())
            .writer(inactiveUserWriter())
            .build();
    }

    @Bean
    @StepScope
    public QueueItemReader inactiveUserReader() {
        List targetUsers =
            userRepository.findBylastModifiedAtBeforeAndStatusEquals(
                LocalDateTime.now().minusYears(1),
                true);
        log.info("InActive Target User Count: " + targetUsers.size());

        return new QueueItemReader<>(targetUsers);
    }

    @Bean
    @StepScope
    public ItemProcessor inactiveUserProcessor() {
        return User::toInActive;
    }

    @Bean
    @StepScope
    public ItemWriter inactiveUserWriter() {
        return (userRepository::saveAll);
    }
}

스프링 배치를 사용하기 위해서는 DB에 배치 처리를 위한 테이블들이 필요합니다.
schema.mysql.sql 파일을 통해 테이블 생성 후 실행 가능 Spring Batch 개발기 ( 4. MetaData테이블 )
이후 스케줄러를 적용하여 ApplicationContext에 있는 Job bean을 가져와 JobLauncher로 실행시킬 수 있습니다.

✔️ 스케쥴러란?

특정한 시간에 등록한 작업을 자동으로 실행시키는 것
Spring Scheduler, Quartz

휴먼 계정 처리 - 스케쥴러 선택 이유

스케쥴러는 한 번에 많은 양의 데이터를 처리하려면 성능 이슈가 발생할 수 있기 때문에 대용량 데이터 처리에는 부적합합니다. 하지만 현재 서비스는 출시 직후 예상 유저가 약 200명이기 때문에 간단한 스케쥴링 작업에 적합합니다.

🌱 스프링 MVC 2

Wed, 31 May 2023 00:11:53 GMT

✔️ 타임리프 기본기능

컨텐츠안에 내용 바로 삽입하기 - [[…]]


  th:text 사용 
  컨텐츠 안에서 직접 출력하기 = [[${data}]]

이스케이프 - th:utext / [(…)]

문자를 태그로 변환하지 않고 문자 그대로 출력

th: text : 이스케이프 VS th: utext: 언이스케이프
[[…]] : 이스케이프 VS [(…)] : 언이스케이프

※ 이스케이프를 기본으로 하고 꼭 필요할 때만 언이스케이프 사용

지역변수 - th:with


  처음 사람의 이름은

Param, Session, Spring Bean

Thymeleaf 에서 지원하는 이름으로 바로 꺼내쓸 수 있다.

Request Parameter = 
session = 
spring bean =

URL

basic url
hello query param
path variable
path variable + query parameter

리터럴 - 작은 따옴표

소스코드 상의 고정된 값을 말하는 용어
타임리프에서 리터럴은 작은 따옴표로 감싸야한다.

'hello' + ' world!' = 
 'hello world!' = 
 'hello ' + ${data} = 
 리터럴 대체 |hello ${data}| =

연산 - No-Operation

코드

  
  
    산술 연산
      
        10 + 2 = 
        10 % 2 == 0 = 
      
    
    비교 연산
      
        1 > 10 = 
        1 gt 10 = 
        1 >= 10 = 
        1 ge 10 = 
        1 == 10 = 
        1 != 10 = 
      
    
    조건식
      
        (10 % 2 == 0)? '짝수':'홀수' = 
      
    
    Elvis 연산자
      
        ${data}?: '데이터가 없습니다.' = 
        ${nullData}?: '데이터가 없습니다.' = 
      
    
    No-Operation
      
        ${data}?: _ = 데이터가 없습니다.
        ${nullData}?: _ = 데이터가없습니다.

No-Operation
- _ 인 경우 마치 타임리프가 실행되지 않는 것 처럼 동작한다. 이것을 잘 사용하면 HTML 의 내용 그대로 활용할 수 있다. 마지막 예를 보면 데이터가 없습니다. 부분이 그대로 출력된다

속성 값 설정 - 추가, Checked

속성 추가

  - th:attrappend = 

  - th:attrprepend = 

  - th:classappend =

Checked 속성
- 기존의 checked는 false로 설정해도 무조건 체크가 되어져서 렌더링된다. 하지만 th:ckecked를 사용하면 false로 설정할 경우 checked 설정 자체를 없애준다.
  
```html
- checked o
- checked x

반복 - th:each , ___Stat

___Stat
- index : 0부터 시작하는 값
- count : 1부터 시작하는 값
- size : 전체 사이즈
- even , odd : 홀수, 짝수 여부( boolean )
- first , last :처음, 마지막 여부( boolean )
- current : 현재 객체
```
username
username
0

index = 
count = 
size = 
even? = 
odd? = 
first? = 
last? = 
current = 
```

조건부 - if, unless, switch/case

조건을 만족하지 못할 시 해당 태그 전체가 삭제된다.

주석

HTML 주석
```
  
```

타임리프 파서 주석
```
  
  
  html data
  
```

타임리프 프로토타입 주석 - 파일 자체를 열때는 주석처리, 타임리프를 사용해서 렌더링되는 경우에는 주석 처리 X
```
  
```

블록 - 타임리프 자체 태그 th:block

자바스크립트 인라인

자바스크립트 인라인 사용전
사용

템플릿 조각 (컴포넌트)

컴포넌트 선언 코드

  
   파라미터 자리 입니다.

컴포넌트 사용 코드
- replace 대신 insert 사용 시 div 태그 내부로 삽입
```
파라미터 사용
```

템플릿 레이아웃

레이아웃 선언 코드

  
  
   레이아웃 타이틀

555

SQL Error: 1054, SQLState: 42S22

SQL Error: 1451, SQLState: 23000

회원 탈퇴 시 발생한 에러

[리눅스] 서버 로그 관리

스프링 로그

Logback

Log Level

리눅스 서버 로그 관리

로테이션

Nginx

/etc/nginx/nginx.conf

/etc/logroate.conf

Logrotate

DORO 운영 서버 수정사항

💠 OSIV 성능최적화

💠 Application Properties 분리

운영 서버 / 개발 서버

💠 DB PK 테이블별 Auto Increment 적용

💠 시큐리티 컨텍스트 홀더 초기화 AOP 적용

적용 대상

💠 보안 강화 - 해킹 시도 차단

💠 핀포인트 도입

💠 API 성능 테스트 - 쿼리 최적화

💠 테스트 코드 작성

💠 회원가입 시 학교, 학과 검색 선택

[EC2] Error: Request timed out

에러 로그

체크 사항

AWS

Nginx

Docker

해결

📂 스프링 DB 2

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

용어 정리

SQL Mapper

ORM

DTO

@EventListener

ItemServiceApplication 설정 + 프로필

프로필

✔️ 스프링 JdbcTemplete

JdbcTemplete 정리

장점

단점

구현 - V1

코드

Save 메서드

FindById 메서드

NamedParameterJdbcTemplate - V2

1.BeanPropertySqlParamterSource

2.MapSqlParamterSource, 3.Map

BeanPropertyRowMapper

별칭

관례의 불일치

SimpleJdbcInsert - V3

✔️ DB관련 테스트

DB 연동

SpringBootTest

DB 분리

테스트의 중요 원칙

데이터 롤백

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

Transactional Annotation을 통한 구현

임베디드 모드 DB

임베디드 모드

직접 설정

스프링 부트 사용

✔️ MyBatis

장점

단점

설정

적용

ItemMapper 인터페이스

XML 파일

특수문자 사용

원리

매퍼 구현체

기타기능

`/etc/nginx/nginx.conf`

`/etc/logroate.conf`

`NamedParameterJdbcTemplate` - V2

1.`BeanPropertySqlParamterSource`

2.`MapSqlParamterSource`, 3.`Map`

`BeanPropertyRowMapper`