[Spring Batch] The Domain Language of Batch - (3) ExecutionContext

https://docs.spring.io/spring-batch/docs/current/reference/html/domain.html#executioncontext

The Domain Language of Batch

 

틀린 해석이 있다면 알려주세요 🪵

---

 

 

 

ExecutionContext

ExecutionContext은 개발자에게 개체 또는 개체로 범위가 지정된 영구상태의 저장할 장소를 제공하기 위해 프레임워크에서 유지되고 제어되는 key-value collection을 나타낸다. 이는 재시작을 용이하게 한다. (For those familiar with Quartz, it is very similar to JobDataMap.) flat file input 을 예로 들면 개별 라인이 처리되는 동안 프레임워크는 commit 지점에서 이를 주기적으로 유지한다

실행 중 치명적인 오류가 발생하거나 전원이 꺼지더라도 상태를 저장할 수 있다.

 

All that is needed is to put the current number of lines read into the context, as the following example shows, and the framework does the rest

executionContext.putLong(getKey(LINES_READ_COUNT), reader.getPosition());

 

 

Using the EndOfDay example from the Job stereotypes section as an example, assume there is one step, loadData, that loads a file into the database. After the first failed run, the metadata tables would look like the following example:

Table 9. BATCH_JOB_INSTANCE

JOB_INST_ID	JOB_NAME
1	EndOfDayJob

Table 10. BATCH_JOB_EXECUTION_PARAMS

JOB_INST_ID	TYPE_CD	KEY_NAME	DATE_VAL
1	DATE	schedule.Date	2017-01-01

Table 11. BATCH_JOB_EXECUTION

JOB_EXEC_ID	JOB_INST_ID	START_TIME	END_TIME	STATUS
1	1	2017-01-01 21:00	2017-01-01 21:30	FAILED

Table 12. BATCH_STEP_EXECUTION

STEP_EXEC_ID	JOB_EXEC_ID	STEP_NAME	START_TIME	END_TIME	STATUS
1	1	loadData	2017-01-01 21:00	2017-01-01 21:30	FAILED

Table 13. BATCH_STEP_EXECUTION_CONTEXT

STEP_EXEC_ID	SHORT_CONTEXT
1	{piece.count=40321}

 

 

>>  Step은 30분 동안 실행되었고 40,321개의 "piece"을 처리했으며, 이는 이 시나리오에서 파일의 라인을 나타낸다.

이 값은 프레임워크에서 각 커밋 직전에 업데이트되며 ExecutionContext. 커밋 전에 알림을 받으려면 다양한 StepListener구현 중 하나(또는 ItemStream)가 필요하며 이에 대해서는 뒤에 설명한다. Job 이전 예와 마찬가지로 다음 날 다시 시작한다고 하면, ExecutionContext 마지막 실행의 값이 데이터베이스에서 재구성된다. temReader가 열리면 다음 예제와 같이 컨텍스트에 저장된 상태가 있는지 확인하고 거기에서 자체적으로 초기화할 수 있다

 

if (executionContext.containsKey(getKey(LINES_READ_COUNT))) {
    log.debug("Initializing for restart. Restart data is: " + executionContext);

    long lineCount = executionContext.getLong(getKey(LINES_READ_COUNT));

    LineReader reader = getReader();

    Object record = "";
    while (reader.getPosition() < lineCount && record != null) {
        record = readLine();
    }
}

 

앞의 코드 실행 후 현재 라인은 40,332 줄이고 Step이 중단된 위치에서부터 다시 시작한다

실행 자체에 대해 유지해야 하는 통계에 ExecutionContext를 사용할 수도 있다

예를 들어 플랫 파일에 여러 라인에 걸쳐 존재하는 처리 주문이 포함된 경우 처리된 주문 수(본문에서 처리된 총 주문 수와 함께 Step의 끝 - 읽은 라인 수 다름)를 저장해야 이메일을 보낼 수 있다.

프레임워크는 개별 JobInstance로 범위를 올바르게 지정하기 위해 개발자를 위해 이를 저장하는 것을 처리한다.

기존 ExecutionContext를 사용해야 하는지 여부를 아는 것은 매우 어려울 수 있다.

예를 들어 위의 EndOfDay 예를 사용하여 01-01 실행이 두 번째로 다시 시작되면 프레임워크는 동일한 JobInstance임을 인식하고 개별 단계별로 ExecutionContext를 데이터베이스에서 끌어와 전달한다. (StepExecution의 일부로) Step 자체에.

반대로 01-02 실행의 경우 프레임워크는 다른 인스턴스임을 인식하므로 빈 컨텍스트를 Step에 전달해야 한다. 올바른 시간에 상태가 제공되도록 하기 위해 프레임워크가 개발자를 위해 만드는 이러한 유형의 결정이 많이 있다. 주어진 시간에 StepExecution당 정확히 하나의 ExecutionContext가 존재한다는 점에 유의하는 것도 중요하다.

 

ExecutionContext의 클라이언트는 공유 키스페이스를 생성하므로 주의해야 한다. 따라서 값을 입력할 때 데이터를 덮어쓰지 않도록 주의해야 한다. 그러나 Step은 컨텍스트에 데이터를 전혀 저장하지 않으므로 프레임워크에 악영향을 미칠 방법이 없다.  JobExecution당 하나 이상의 ExecutionContext가 있고 모든 StepExecution마다 하나가 있다.

 

ExecutionContext ecStep = stepExecution.getExecutionContext();
ExecutionContext ecJob = jobExecution.getExecutionContext();
//ecStep does not equal ecJob

ecStep과 ecJob은 같지 않다. 둘은 서로 다른 두개의 ExcutionContext이다

Step으로 범위가 지정된 것은 Step의 모든 comit지점에 저장이 되지만, Job은 번위가 지정된 모든 단계 실행 사이에 지장된다