Eclipse Lab : 팀 블로그

Job

Job은 Job Manager에 의해 스케쥴 되고 실행 될 수 있는 작업 단위이다. 하지만 라이프 싸이클이 작업 주기에 한정되지는 않는다. Job이 한 번 완료되고 난 후에, 다시 스케쥴 될 수도 있다.

Job의 기본 사용법

1. Job을 상속 받아 적절한 작업을 기술 한다.
2. 해당 Job의 인스턴스에 schedule()을 호출하여 작업을 스케쥴 한다.
   

Job job = new MyJob("테스트 작업");
job.schedule();

Job은 현재 동작을 가리키는 상태를 가진다. Job이 처음 만들어졌을 때 상태는 NONE이 된다. 실행을 위해 스케쥴 되면, WAITING 상태가 되며, 수행중에는 RUNNING이 된다. 수행이 완료되거나 취소 되면 다시 NONE상태가 된다.

Job은 SLEEPING 상태로도 진입이 가능한다, 사용자가 Job.sleep()을 호출하거나, Job.schedule(delay)의 형태로 지연시간을 갖고 스케쥴 된 경우 이 상태가 된다. WAITING 상태인 Job들만 SLEEPING 상태로 넘어갈 수 있다. 이 Job들은 Job.wakeUp()으로 깨울 수 있으며 WAITING 상태로 돌아간다.

Job들은 우선순위를 가질 수 있지만, 높은 우선순위가 낮은 우선순위보다 먼저 수행된다는 보증을 가지고 있지는 않다. 

schedule

스케쥴 메소드는 현재 상태에 따라 다음과 같이 작동한다:

• NONE - 상태가 없는 경우: 스케쥴 된다
• WATING - 스케쥴 되었지만 아직 실행되지 않은 경우: 아무일도 하지 않음
• RUNNING - 실행중인 경우: 수행이 완료 된 후, 다시 스케쥴 됨, 이 상태에서 다시 스케쥴이 오더라도 한 번만 스케쥴 된다.

Job Manager

Job Manager는 Job들에 대해 스케쥴링, 쿼링, 관리 및 록을 제공하며, 다음과 같은 서비스를 공급한다:

• 대기중(WAITING)인 Job들이 실행 될 수 있게금, 큐를 관리한다.
• Job Family 라고 불리는 작업 그룹을 관리하도록 해 준다.
• 리스너들이 잡의 진행상황을 통보 받을 수 익도록 해 준다.
• Job이나 Job Family가 끝나기를 기다리는 클라이언트에게 피드백을 공급한다.

Job Manager는 일반적인 경우 직접 제어하지 않는다. 클라이언트는 Job.schedule()을 이용하여 Job Manager를 간접적으로 이용한다.

Schedule Rule

스케쥴 룰은 Job이 스케쥴 될 때 함께 JobManager 에 선포되어 효력을 발휘하고, 잡이 끝나면, 해당 잡이 제공했던 스케쥴 룰의 효력도 끝난다. Job은 스케쥴링 룰을 가질 수도 있고, 가지지 않을 수도 있다. 스케쥴링 룰이 없다면, 아무때에나 스케쥴 되고 수행 될 수 있음을 의미한다.

스케쥴 룰은 일반적으로, 특정한 리소스에 대해 배타적으로 작업들이 수행될 되어야 할 때 사용한다. Job.setRule(IScheduleRule)을 통해 Job의 스케쥴링 규칙을 정해 줄 수 있다. 스케쥴링 룰은 서로 포함 또는 배제라는 관계를 갖는데 각각 contains(IScheduleRule)과 isConflicting(IScheduleRule)로 구현된다.

• contains: 한 스케쥴 룰이 다른 스케쥴 룰을 포함한다는 것은 - 편의상 포함되는 룰을 자식, 포함하는 룰을 부모라 한다 - 부모 룰이 선포되어 운영되는 도중, 자식 룰이 함께 선포될 수 있음을 의미한다. 일반적으로 룰이 다른 룰에 대해 아는 것이 없을 경우에는 반드시 false를 리턴해야 한다.
  
• conflict: 두 스케쥴링 룰은 동시에 선포될 수 없으므로, 충돌하는 스케쥴 룰을 가진 Job들은, 먼저 수행된 Job이 끝나 해당 스케쥴링 룰의 운영이 끝난 다음 스케쥴 된다.
  

주로 사용하는 스케쥴링 룰른 IResource에 관한 것이 많다.

• 특정 리소스에 대해 록을 제공하는 룰
  ResourcesPlugin.getWorkspace().getRuleFactory().createRule(IResource)
  이는 매우 유용하면서 필수적인 도구이다. 이를 이용하여, 적절한 lock을 확보하지 않는다면, SVN이나 CVS 플러그인 들이 끔찍한 반응을 해 올 수도 있다.
  

IFile testFile = ....
// testFile 을 동시에 두 작업이 접근하지 못하도록 하는 룰
IScheduleRule fileAccessRule =
    ResourcesPlugin.getWorkspace().getRuleFactory().createRule(testFile);

Job job = new HandleFileJob();
job.setRule(fileAccessRule);

job.schedule();

리소스(IResource)들은 그 자체가 ISchedulRule이기도 하므로, 곧바로 룰로 사용해도 된다.

// 이클립스 AutoBuildJob의 생성자
AutoBuildJob(Workspace workspace) {
	super(Messages.events_building_0);
	
	// 워크스페이스 루트 자체를 룰로 지정한다.
	// 빌드가 끝나기 전까지 어떤 다른 Job도 워크스페이스에 접근 할 수 없다.
	setRule(workspace.getRoot());

	setPriority(BUILD);
	isAutoBuilding = workspace.isAutoBuilding();
	this.workspace = workspace;
	this.preferences.addPropertyChangeListener(this);
}

Job의 종류

작업이 진행되는 배경적 특성에 따라 몇 가지 유용한 부모 Job 클래스들이 공급된다.

• WorkspaceJob: 워크스페이스 잡은, 잡이 종료될 때 까지 발생하는 모든 리소스 변경 통지를 멈춰두었다 작업이 완료된후 일시 통보하는 기능을 가진다. 만약, 수많은 파일을 일괄적으로 변조하는 작업을 수행할 때 이러한 조치를 취하지 않는다면, 자동 빌딩이 끝 없이 스케쥴되는 골치 아픈 광경을 볼 수 있게 될 것이다.
  
• WorkbenchJob: 원래는 워크벤치가 소멸되거나 완전히 준비되기 전에 작업이 수행되는 것을 방지하기 위해 고안 되었지만, 작업이 UI수정을 포함할 때도 많이 쓰인다. UI 스레드와 동기화되어 실행되기 때문이다. - 워크밴치가 시작 되자 마자 무언가가 실행되게 하고 싶다면, 이를 상속하는 것이 좋다.

Job Family

Job 들은 필요에 따라 특정 분류그룹을 가질 수 있으며, 여러 그룹에 속할 수도 있다. public boolean belongsTo(Object family)를 오버라이드 하여, 특정 Job이 어떤 패밀리에 속하는지 기술 할 수 있다. Job.getJobManager()는 패밀리 객체를 통한 Job 찾기등의 API를 공급하기 때문에, 각 Job들이 스캐쥴되거나 실행될때마다 같은 그룹에 속한 Job의 상태에 따라 반응하게 하는 것이 가능하다. 예를 들어, 여러번의 업데이트 Job 중 가장 마지막에 스케쥴 된 Job만 실행되게 할 수 있다.

ChangeRecorder

ChangeRecorder는 org.eclipse.emf.ecore.change에 포함되어 있는 도구로, EObject를 상속받은 객체들의 변경을 추적할 수 있는 도구이다. 이를 사용하는 예제는 다음과 같다:

// 임의의 ecore 모델을 하나 만든다.
Person jiyul = MyFactory.eINSTANCE.createPerson();
jiyul.setName("Jiyul");

// 롤백 디스크립션 작성 시작
ChangeRecorder recorder = new ChangeRecorder(jiyul);

// 모델을 변경 시킴
jiyul.setName("Sid Vicious");

// 녹화 종료
ChangeDescription rollbackDescription = recorder.endRecording();

// 녹화된 내용을 역으로 적용
rollbackDescription.apply();

System.out.println(jiyul.getName());

위의 코드를 수행 하면, jiyul:Person의 name을 시드 비샤스로 지정하였지만, 화면에는 지율이 출력된다. ChangeRecorder가 jiyul:Person이 발생시키는 모든 Notification을 수집하여 역으로 수행할 수 있는 ChangeDescription을 만들어 주기 때문이다. ChangeDescription은 녹화 이외에도 다른 방법으로도 생성할 수 있다.

트랜잭션 처리

위의 예제를 좀 더 일반화된 트랜잭션 관리 코드로 나타내면 다음과 같은 모양이 된다:

ChangeRecorder recorder = new ChangeRecorder(model);
try{
	모델을 조작하는 코드들이 여기에 위치한다...
}catch(Exception e){
	// 모델을 다루는 작업 도중 문제가 발생한 경우 롤백 시킨다.
	recorder.endRecording().apply();
}

ChangeDescription

그런데 재미있는 점은 모델의 변경을 기술하는 객체인 ChangeDescription 역시, EObject를 상속받는다는 점이다. 이 말은 ChangeDescription 역시 EMF를 통해 제네레이트 된 코드라는 뜻이다. 다시 말해 ChangeDescription은 XML로 시리얼라이즈 될 수 있다. 이 사실은 도전적인 독자들에게, XML로 시리얼라이즈된 ChangeDescription을 이용하여, 네트워크 너머의 모델을 수정할 수 있다라는 멋진 아이디어에 들뜨게 할 것이다. ChangeDescription은 ChangeFactory 및 ChangePackage를 이용하여 직접만들거나, 리소스로 부터 읽거나 쓸수 있다. 여기서는 간단한 예제만을 다뤄 보이겠다:

// 녹화 종료
ChangeDescription description = recorder.endRecording();

// 변경된 내용을 xml로 출력
ResourceSet rs = new ResourceSetImpl();
XMLResource resource = 
    (XMLResource) rs.createResource(URI.createFileURI("test.xml"));
resource.getContents().add(description);
resource.save(System.out, new HashMap<Object, Object>());

위의 코드를 수행하면 ChangeDescription의 내용이 시리얼라이즈 되는 것을 확인 할 수 있을 것이다.