공대키메라

최근에 열심히 이직 준비를 하고 있는 오늘의 키메라! 필자는 이와 같은 질문을 받았다 면접관 : JPA를 사용해 보셨다고요? JPA가 뭐죠?키메라 : 네! JPA는 Java Persistent API로 ORM을 위해 사용되는 인터페이스입니다.면접관 : 그러면 JPA에는 왜 save 시에 @Transactional을 붙여야 할까요? 안되다가 마법같이 데이터 조작 작업이 되더라고요.키메라 : 아... 그건 잘... 모르겠는데요?면접관 : ???키메라 : ??? 이에 대한 대답을 찾기 위해 글을 정리했다. 막상 쭈욱 다시 정리하니 별거 없는데 참... ㅠㅠ 1. 트랜잭션에 대해서트랜잭션이란 데이터베이스의 상태를 변화시키기 위해서 수행되는 작업의 단위를 뜻한다. 트랜잭션의 특징은 원자성, 일관성, 독립성..

지난 시간에는 StepExecutionListener ~ Example Tasklet Implementation을 읽어보았다 (지난 내용은 여기 클릭!) 이번 시간에는 Controlling Step Flow부터 다시 읽어볼 것이다. Controlling Step Flow 가지고 있는 job안에서 step을 함께 그룹핑 하는 능력이 한 step에서 다른 step으로 어떻게 job이 "흘러가는지" 제어할 필요가 있다. Step의 실패는 Job 이 실패한다는것을 꼭 의미하는건 아니다. 또한 다음에 어떤 단계를 실행해야 하는지 결정하는 "성공" 유형이 두 가지 이상 있을 수 있다. Step의 그룹이 어떻게 설정되냐에 따라서 특정 step이 전혀 처리되지 않을 수 도 있다. 1. Sequential Flow 가장..

지난 시간에는 스킵 로직을 설정하는 것에서부터 Step 실행에 중도에 끼어드는 방법까지 알아 보았다. (Configuring Skip Logic ~ Intercepting Step Execution) 지난 내용은 여기 클릭! 이번 시간에는 StepExecutionListener에서부터 다시 이어서 읽어보도록 하겠다. Listener? 리스너는 배치 흐름 중에 Job, Step, Chunk 실행 전후에 어떤 일을 하도록 하는 Interceptor 개념의 클래스다. 스프링 MVC의 Interceptor가 실제로 HandlerAdapater 호출 전후로 Interceptor가 호출되는 것처럼 Job, Step, Chunk 전후로 오버라이딩된 메서드가 호출된다. 주로 각 단계별로 로그 기록을 남기거나, 진행된 ..

이번 시간에는 지난번에 읽던 Step 설정을 이어서 읽어볼 것이다. (지난 내용이 궁금하면 여기 클릭!) 1. Configuring Skip Logic 처리하는동안 맞닥드린 에러들은 Step 의 실패로 결과를 초래하는 대신에 생략해야만 하는 시나리오가 있다. 이것은 데이터를 그것이 무슨 의미인지 이해하는 누군가에 의해 만들어지는 결정이다. 예를 들어, 금융 데이터는 돈이 전동될 때 스킵할 수 없는데 그것이 완벽한 정확함을 필요로하기 때문이다. 반면에 벤더의 리스트를 로딩하는 것은 스킵을 가능케 할 수도 있다. 만약 벤더가 부정확하게 포맷되어잇고 필요한 정보가 빠져 있다면 이슈가 없다. 대개, 이렇나 나쁜 기록들이 또한 쌓이는데 listener에 대해 논의할 때 나중에 다룬다. 다음 Java 예시가 ski..

지난 시간에는 Job을 설정하고 실행하는 여러 방법에 대해 알아보았다. (지난 내용이 궁금하면 여기 클릭!) 이번에는 Step을 어떻게 설정하는지에 대한 글을 읽어볼 것이다. 와우! 너무 기대되는걸? 꿀잼 ^^ 1. Configuring a Step domain chapter에서 논의된 Step은 배치잡의 독립적으로 연속적인 절(phase)를 캡슐화한 도메인 객체로 실제 배치 처리를 정의하고 제어하는데 필요한 모든 정보를 포함한다. 모든 주어진 Step의 내용물은 Job을 쓰는(writing) 개발자의 재량에 달려있기 때문에 이것은 필연적으로 모호한 묘사다(개발자들이 각자 만들어 쓰는 것이라 Step에 대한 의미가 애매할 수 밖에 없다는 것 같다!). Step은 개발자가 요구하는것에 따라 간단할 수도 복..

이번 시간에는 지난에 보던 글에 이어서 JobRegistry부터 다시 읽어볼 것이다. (지난 내용이 궁금하면 여기 클릭!) 1. JobRegistry JobRegistry(그리고 그 부모 인터페이스인 JobLocator) 는 강제적이지는 않지만 context에서 어떤 잡이 사용할 수 있는지 추적하길 원하면 유용할 수 있다. 또한 context가 어디서든지 생성되어왔을 때 application context안에서 job을 중앙에서 모으기에 유용하다. 또 등록된 잡의 다른 속성이나 이름을 수정하기 위해 커스텀 JobRegistry 구현체를 사용할 수 있다. @EnableBatchProcessing을 사용할 때 JobRegistry가 제공된다. 다음 예시는 자신의 JobRegistry를 설정할 수 있는지 보인..

지난 시간에는 잡 설정 및 실행을 읽다가 멈추었다. (지난 내용이 궁금하면 여기 클릭!) 이번에는 지난 내용에 이어서 다시 글을 읽어보려고 한다. 이번 섹션도 아주 길지만 한 번 열심히 읽어보려고 한다. 1. Changing the Table prefix JpaRepository의 또다른 수정 가능한 속성은 메타데이터 테이블의 접두사다. 기본적으로 "BATCH_"로 시작한다. BATCH_JOB_EXECUTION과 BATCH_STEP_EXECUTION은 두개의 예이다. 하지만 이 접두사를 수정할 잠재적인 이유가 있다. 만약 스카미의 이름들이 테이블 이름들에 추가를 하거나 메타데이터 테이블의 하나 이상이 같은 스키마에 있을 필요가 있다면 테이블 접두사는 변경되어야 한다. @Configuration @Enab..

지난 시간에는 Spring Batch의 도메인들에 대해 읽어보았다. (지난 내용이 궁금하면 여기 클릭!) 지난 내용은 spring batch에서 사용되는 domain들에 대해 설명했고 실제로 어떻게 사용하는지에 대한 설명은 없었기에 좀 재미없었을 수 있다. (맞아 쌉노잼이야 에잉 퉤텟!) 이번 시간에는 잡을 설정하고 실행하는 방법에 대해 읽어볼 것이다. domain section에서 전반적인 아키텍처 디자인을 다음 그림을 사용해서 논의했다. Job 객체가 Step을 위한 간단한 컨테이너처럼 보이지만 많은 설정 옵션을 알아야 한다. 더욱이, 어떻게 Job이 작동할 수 있고 어떻게 그 메타데이터가 실행동안 저장될 수 있는지에 대한 많은 옵션을 고려해야한다. 이 챕터는 다양한 설정 옵션과 Job의 런타임 관심..

지난 시간에 배치의 도메인 언어중 Job, JobInstance, JobParameter, JobExecution에 대해 알아보았다. (지난 내용을 보고 싶다면 여기 클릭!) 저번에 내용이 너무 길었던 관계로 끊은 부분에서 이어서 Step부터 다시 읽을 것이다. 1. Step Step은 한 배치 잡(batch job)의 독립적이고 연속적인 단계를 캡슐화한 하나의 도매인 객체이다. 그러므로 모든 job은 하나 혹은 더 많은 Step들로 구성되있다. Step은 실제 배치 처리를 정의하고 제어하는에 필요한 모든 정보를 포함한다. 이것은 어쩔수없이 모호한 묘사인데(?) 아무 Step의 내용들이 Job을 사용하는 개발자의 재량에 달렸기 때문이다. Step은 개발자의 요구사항에 따라 간단하거나 복잡할 수도 있다. ..

지난 시간에 Spring Batch Architecture, Spring Batch Principles and Guidelines 그리고 Spring Processing Strategies 와 약간의 지식들에 대해 보았다. (지난 내용을 보고 싶다면 여기 클릭!) 너무 전략 부분이 쓸데없이 길었던것 같아서 중도에 읽다가 말았다.ㅠㅠ... 지극히 내 개인적인 생각으로는 아 이거 이렇게 해도 되나 싶을 때 다시 보면 될 것 같다.(너무 원론적이야!) 이번에는 배치의 도메인 언어 부분을 읽어볼 것이다. 그리고 읽는 와중에 이런 Job, JobLauncher같은 특별한 것들은 해석이 안된다. 그래서 되도록 본연의 개념을 더 알 수 있도록 영어로 그대로 적고자 한다. (영어 최고야 아잉!) 모든 경험있는 배치 설..