모집공고 상태 자동변경 로직 작성 완료

[SongJaeHoonn]

Summary

#353

원래 모집 공고의 상태를 직접 String으로 수정해야 하는 문제점이 있었습니다.
따라서 모집 시작 시각, 모집 종료 시각을 기준으로 모집 공고의 상태를 자동으로 변경하는 로직을 구현했습니다.

Tasks

• 모집 공고 상태 enum 마련
• 모집 공고 상태 자동 변경 스케줄링 구현

ETC

스케줄링을 사용하는 로직에서 Transaction 어노테이션을 적용하면, 변경 객체가 준영속상태가 되는 문제가 있었습니다.
따라서 스케줄링 로직과 Transaction 어노테이션이 동시에 돌아가지 않는 이슈로 인해 직접 객체의 변경 사항을 커밋했습니다.

Screenshot

현재시각 < 모집 시작시각

모집 시작시각 < 현재시각 < 모집 종료시각

현재시각 > 모집 종료시각

모집공고 조회

모집공고 일정 수정 전

모집공고 일정 수정 후(기간 연장)

-> 다시 open 상태로 즉각 변경됨

[mingmingmon]

제가 개념적인 부분이 부족한 것 같아 질문드립니다!

스케쥴링 로직과 transaction 어노테이션의 혼용이 문제가 되는 이유를 더 구체적으로 설명해주실 수 있나요? 준영속성 관련된 이야기도 해주시면 이해하는데 도움이 될 것 같습니다!

[SongJaeHoonn]

@mingmingmon

엔티티의 준영속 상태는, 해당 객체가 이미 DB에 한 번 저장되어 다시 나와 JPA의 영속성 컨텍스트가 더 이상 관리하지 않는 상태를 말합니다.

해당 작업을 하다가, 스케줄링이 걸린 메소드에서 트랜잭션이 제대로 적용되지 않아, 코드 상에서는 모집 상태가 변경되지만 실제로는 커밋이 되지 않아 DB에 업데이트된 사항이 적용되지 않는 문제가 있었습니다.

오랫동안 고민해서 찾아보니, 스프링의 스케줄러를 이용한 작업에서 트랜잭션 매니저와 관련된 문제(@EnableTransactionManagement를 통해서 DataSourceTransactionManager로 구성된 경우 하이버네이트의 begin 메소드가 AbstractTransactionImpl을 부르지 않는 문제) 때문에 트랜잭션 처리가 불가능하다는 것을 알아냈고,

따라서 트랜잭션 매니저를 직접 이용해서 커밋과 머지를 직접 하는 방식으로 구현했습니다.

[limehee]

DB 구조 변경에 따른 기존 데이터 마이그레이션 및 변경 사항을 반영하는 쿼리문입니다.

-- 기존 데이터를 업데이트하여 "종료"를 "CLOSED"로 변경
UPDATE recruitment
SET status = 'CLOSED'
WHERE status = '종료';

-- 기존 체크 제약 조건을 삭제
ALTER TABLE recruitment
    DROP CONSTRAINT IF EXISTS recruitment_status_check;

-- 새로운 체크 제약 조건 추가
ALTER TABLE recruitment
    ADD CONSTRAINT recruitment_status_check
    CHECK ((status)::text = ANY ((ARRAY['UPCOMING'::character varying, 'OPEN'::character varying, 'CLOSED'::character varying])::text[]));