KR100313844B1 - 프레임워크환경에서도구데이터객체를로킹하는메카니즘 - Google Patents

Abstract

도구(tool) 데이터와 같은 데이터가 일반적으로 액세스 가능할 경우, 동시에 실행중인 유저 프로세스들(concurrent user processes)은 중복하여 갱신(modification)할 수 있으며, 그 결과 데이터를 불완전 또는 불가해(不可解: incomprehensible) 상태로 만들 위험이 존재한다. 본 발명은 이러한 것을 방지하기 위한 로킹 메카니즘(locking mechanism)을 제공한다. 로크 객체들(lock objects)은 풀(pool) 또는 저장소(repository) 내에 유지된다. 두 가지 형식의 로킹 객체가 제공되는데, 하나는 다수의 유저 프로세스에 의해 공유될 수 있으며 로킹된 데이터에 대해 판독 액세스만을 허가하는 공유 로크(shareable locks)이고, 다른 하나는 한 번에 하나의 유저 프로세스에 의해서만 사용 가능하며 사용중인(owning) 프로세스가 로킹된 데이터를 갱신(modify)하도록 허가하는 배타 로크(exclusive locks)이다.

Description

프레임워크 환경에서 도구 데이터 객체를 로킹하는 메카니즘{LOCKING TOOL DATA OBJECTS IN A FRAMEWORK ENVIRONMENT}

본 발명은 데이터 처리 분야에 관한 것으로, 구체적으로는 공통 액세스 도구 데이터(common access tool data)에 대한 로킹 메카니즘에 관한 것이다

본 출원인이 카나다에 출원한 "An Object Oriented Framework Mechanism Providing Common Object Relationship and Context Management for Multiple Tools"라는 명칭의 특허 출원(IBM Docket No. CA9-97-002)은 도구 데이터 관리용 프레임워크 메카니즘에 관한 것이다. 본 발명의 로킹 메카니즘은 상기 특허 출원에 기술된 환경에 사용될 수 있다.

도구(tool)는 유저용 데이터를 저장, 관리 및 검색하는 소프트웨어, 프로그램, 또는 프로그램 내의 애플리케이션 모듈의 유닛이다. 개발중인 새로운 도구는 모두 도구 데이터용 저장 메카니즘을 설계하고, 구현하며 검사하는 작업을 포함한다. 따라서, 새로운 도구의 개발과 관련된 비용이(시간과 경비 양자에 있어서) 적지 않게 든다.

대다수 도구는 흔히 데이터를 저장 및 관리하기 위한 자체 메카니즘들을 포함하는데, 이들 메카니즘은 대개 독점적(proprietary)이다. 여기서 독점적이라는 것(proprietary)은 그 메카니즘을 구현하기 위한 세부 사항들이 다른 도구 제작자들 또는 개발자들과 공유되지 않는다는 것을 의미한다. 이러한 독점은 개별 유저의 요구를 충족시키기 위해 기존의 증명된 도구들을 커스텀화(customize)하고 확장시키는데 많은 문제점들을 야기한다. 예를 들어, 도구의 인터페이스(interface) 또는 뷰(view) 부분이 도구의 저장 메카니즘 또는 모델과 뒤얽히게 되어 기존 뷰(view)들과 새로운 뷰들을 통합하는데 난점을 야기시킬 수 있다. 이러한 현상을 도구의 중립성 결여(lack of neutrality)라고 부른다.

또한, 하나의 도구에 의해 생성된 데이터는 다른 도구에 의해 직접 또는 투명하게(transparently) 사용될 수 없다. 대신, 다른 도구들과 일치하는 다른 포맷(format)에 데이터를 기록하는 "엑스포트(export)" 동작 및 다른 포맷의 데이터를 판독하는 "임포트(import)"와 같은 동작들이 요구되며, 도구의 사용자는 도구간에 데이터를 엑스포트 또는 임포트하는 동작을 조심스럽게 선택해야만 한다

또한, 다른 포맷으로부터 임포트된 데이터 부분은 임포팅 도구의 데이터 저장에 대해 양립할 수 없거나 그러한 데이터 저장과 모순되어 즉시 폐기될 수도 있다. 이것은 정보의 라운드 트립 완전성(round trip integrity)을 손상시키며, 하나 이상의 도구에서 정보를 반복적으로 개발하는 것이 어렵게 되거나 불가능하게 된다.

결국, 도구 개발자들은 유사한 데이터를 관리하는 다른 도구에 대한 수정(revision) 또는 개발을 모니터(monitor)해야 하며, 그에 대응하는 새로운 데이터 포맷을 엑스포트 및 임포트하기 위해 새로운 기능을 추가해야 한다. 새로운 엑스포트 및 임포트 기능을 개발하고 검사하는 직접적 비용(raw expense) 외에, 새로운 포맷이 소개되는 시점과 포맷을 핸들링하기 위하여 다른 도구들에서 임포트 및 엑스포트 기능을 이용할 수 있게 되는 시점 간에 시간의 지체가 존재한다.

객체 지향(object oriented: OO) 프로그래밍 기술, 특히 OO 프레임워크 기술은 기존 도구들을 계속 수정(rework)하는데 드는 비용 문제를 해소하는 방법을 제공하며, 다중 도구들을 사용함에 있어서 데이터의 완전성(integrity)을 제공한다.

객체 지향 기술(Object Oriented Technoloy) 대(對) 절차 기술(Procedural Technoloy)

본 발명이 특정 OO 기술(즉, OO 프레임워크 기술)에 관한 것이지만, 일반적으로 OO 기술이 (흔히 절차 기술(procedural technoloy)로 불리우는) 통상적인 프로세스 기반 기술과 매우 다르다는 것을 먼저 이해해야 한다. 상기 2가지 기술들은 모두 동일한 문제점을 해결하기 위해 사용될 수 있지만, 궁극적인 문제 해결 방법은 아주 다르다. 이러한 차이점은 절차 기술의 설계 주안점이 OO 기술의 설계 주안점과 완전히 다르다는 사실로부터 기인한다. 프로세스 기반 설계의 주안점은 문제를 해결하는 전체 프로세스(overall process)에 두고 있다. 이와 반대로 OO 설계에서는 어떻게 하면 솔루션(solution)을 제공하는데 공동 작업이 가능한 독립적인 엔터티의 세트로 문제를 분해시킬 수 있는가에 주안점을 두고 있다. OO 기술의 독립적인 엔터티들은 객체(object)라고 불리운다. 바꾸어 말하면, 절차 기술(procedural technology)에서는 문제가 중첩된(nested) 컴퓨터 프로그램 또는 절차(procedure)의 계층 구조들로 분류되는데 반해 OO 기술에서는 서로 협력하는 객체(cooperating object)의 세트로 분해된다는 점에서 양 기술은 크게 다르다.

OO 프로그래밍의 중요한 특징은 객체가 다른 용도의 다른 조합 또는 상이한 귀속 속성(ascribed different attributes)으로 조합될 수 있는 재사용할 수 있는소프트웨어 엔터티라는 점이다. 이것의 한 예로 미국 West Technologies사의 "Method And System For Generating A User Interface Adaptable To Various Database Management System"이라는 명칭의 미국 특허 제 5,550,971 호를 들 수 있는데, 이 특허는 데이터 베이스 방법(data base scheme)을 나타내는 다양한 "정보 형식"을 가진 유저 인터페이스를 생성하기 위한 동적 모델을 개시하고 있다. 상기 모델은 유저로 하여금 상이한 조회(query) 언어, 데이터 베이스 시스템 및 특정 데이터 베이스 레코드, 필드 및 관계를 학습하게 하지 않고서도 상이한 데이터 베이스 관리 시스템에 적용할 수 있다. 상기 모델은 인스턴스가 실제 데이터 베이스로부터의 다양한 친밀도로 엔터티 및 관계를 나타내는 구체적인 클래스(concrete class)들의 집합에 의해 구현된다. 이러한 클래스들의 객체들은 생성되고 데이터 베이스의 구조를 기술하기 위해 상호 관계를 가지게 된다. 상기 모델 클래스들은 유저 인터페이스를 생성하기 위한 실제 데이터 베이스 구조를 조사하고, 유저 인터페이스에 의해 사용되는 데이터 베이스 정보를 캐슁(cache)하기 위한 표준 인터페이스를 제공한다.

유사한 것들로, 미국 특허 제 5,428,729호(System And Method For Computer Aided Software Engineering, IBM Corporation)는 원시 코드(source code), 검사 데이터와 같은, 데이터 엔터티 문서의 위치를 추적(track)하여 액세스하고, 개발 중인 소프트웨어 프로젝트의 컨텍스트 내에서 컴파일러, 에디터, 링커, 문서 포맷기, 검사 장비(test harnesses)와 같은 데이터 번역(translation of data) 절차를 참조하도록 설계된 시스템을 개시한다. 개발 중인 각 새로운 프로젝트는 메타프로그래머(metaprogrammer)에 의해 템플릿(templete)으로부터 생성되며, GUI(graphic user interface)를 통해 제공된다. 각 유저는 이 "마스터 뷰(master view)"로부터, 유저의 액세스 권한에 따라 선택된 마스터로부터 객체의 서브 세트로 구성된 "유저 뷰"를 클론(clone)할 수 있다. 뷰를 통하여, 구축 절차(build procedure)를 편집, 정의 및 디스패치(dispatch)하고 검사 사례(test case)를 정의 및 디스패치하기 위하여 유저가 데이터 엔터티를 액세스할 수 있는 특정한 플로우(flow)가 기술된다. 액세스 권한은 유저의 "클래스"를 통해 유저들을 객체와 연관시킨다. 상기 특허는 GUI의 외관 및 플로우와 임의(arbitrary)의 상이한 저장소(repository)에 저장된 파일에 액세스를 제공하는 방법, 파일을 소스(source)로부터 타겟 폼(target form)으로 번역하기 위한 규칙을 저장하는 방법 및 프로젝트의 유저-특정 뷰(user-specific views)들을 통해 액세스를 제어하는 방법에 관한 것이다. 그러나 이것은 객체 지향 데이터 통합 프레임워크가 아니므로 이러한 시스템과 본 발명 간의 근본적인 차이는 상기 특허의 시스템이 지정되어 있지만 확장이 가능한 프레임워크 인터페이스들 및 프로토콜들을 통해 다수의 상이한 미지의 도구들 간에 일관된 거동 감각(consistent behavioural feel)을 촉진하도록 설계되어 있지 않다는 점이다.

OO 설계의 당업자들에게 특정한 의미를 갖는 용어들(terms and phase)이 발전되었지만, "프레임워크"란 단어는 가장 넓게 정의된 단어 중의 하나로 사람에 따라 다른 의미를 갖는다. 따라서 두 개의 가상 프레임워크 메카니즘의 특성을 비교할 경우에는 적절한 비교인지를 확인하기 위해 주의를 기울여야 한다.

이하에서 더 명확하게 기술되는 바에 따라, 상기 애플리케이션에서는 프레임워크란 용어가 코어 기능 및 확장 가능한 기능을 갖도록 설계된 OO 메카니즘을 지칭하기 위해 사용된다. 코어 기능은 프레임워크 구매자에 의한 변경을 필요로 하지 않는 프레임워크 메카니즘의 일부분이다. 반면에, 확장 가능한 기능은 프레임워크 구매자에 의해 명백히 커스텀화되며 확장되도록 설계된 프레임워크 메카니즘의 일부분이다.

OO 프레임워크 메카니즘

OO 프레임워크 메카니즘은 일반적으로 OO 솔루션으로 특징지워진다. 그럼에도 불구하고 프레임워크 메카니즘과 기본 OO 솔루션 간에는 근본적인 차이점이 존재한다. 프레임워크 메카니즘은 솔루션의 특정 측면이 커스텀화되고 확장되는 것을 허가하고 촉진하는 방법으로 설계된다. 바꾸어 말하면, 프레임워크 메카니즘은 문제에 대한 솔루션 그 이상이다. 메카니즘은 시간에 따라 변화하는 개별화된 요건에 중점을 두도록 커스텀화될 수 있으며 확장될 수 있는 "살아 있는(living)" 솔루션을 제공한다. 상기에서 논의된 바와 같이 프레임워크 메카니즘의 품질의 커스텀화/확장은 구매자들에게 매우 유용하다. 왜냐하면 프레임워크를 커스텀화 또는 확장하기 위한 비용이 기존의 비-프레임워크 솔루션을 교체하거나 수정하는 비용보다 훨씬 더 싸기 때문이다.

따라서 프레임워크 설계자가 특정 문제의 해결에 착수할 때, 그들은 단순히 개개의 객체들을 설계하고 그 객체들을 어떻게 상호 연관시킬 것인지를 설계하는 것 이상의 작업을 해야 한다. 또한 그들은 프레임워크의 코어 기능(즉 프레임워크 소비자에 의한 커스텀화 및 확장 가능성을 필요로 하지 않는 프레임워크 메카니즘부분) 및 프레임워크의 확장 가능한 기능(즉 가능한 커스텀화 및 확장 가능성을 필요로 하는 프레임워크 부분)을 설계한다. 마지막으로 프레임워크 메카니즘의 궁극적인 가치는 객체 설계 품질 뿐만 아니라 코어 기능을 나타내는 프레임워크의 측면 및 확장 가능한 기능을 나타내는 측면에 관한 디자인 선택에도 관계된다.

프레임워크의 예로 미국 특허 제 5,325,533 호(Engineering System For Modelling Computer Progams, Taligent, Inc)를 들 수 있다. 이 특허에 기술된 프레임워크는 개발 환경에 대한 증가하는 상호 작용, 생성 및 구축 설비(generation and build facilities)들을 제공한다.

본 발명은 애플리케이션(application) 개발 환경에 있어서 공통의 도구 액세스를 위해 데이터 객체를 로킹하기 위한 메카니즘에 관한 것이다. 메카니즘은 로크 객체를 포함하는 저장소로 구성된다. 각각의 로크 객체는 로킹 객체가 완전히 채워지는 시점을 표시하는 참조 카운터를 가지고 있다. 로크 객체는 데이터 객체에 의해 참조될 수 있다.

도 1은 본 발명에 따른 모델 객체에 대한 클래스 계층 구조를 OMT 표기법을 사용하여 도시한 개략적인 다이어그램.

도 2 내지 도 6은 본 발명의 바람직한 실시예에 따른 프레임워크 메카니즘의 클래스 다이어그램을 C++ 언어로 표시한 도면.

도 7은 추가적인 바람직한 실시예에 따른 클래스의 쌍(pair)으로 모델 객체를 도시하는 도 1과 유사한 개략적인 다이어그램.

도 8은 본 발명에 따라 구성된 프레임워크 메카니즘의 계층적 범주 다이어그램을 OMT 표기법을 사용하여 도시한 계층적 카테고리 다이어그램.

도 9는 객체의 로킹 상태를 도시한 상태 다이어그램.

도 10은 본 발명의 바람직한 실시예에서 구현되는 로킹 메카니즘을 개략적으로 도시한 도면.

도 11은 본 발명의 코어 기능을 사용하여 도구 데이터의 갱신을 저장하기 위한 단계를 도시하는 플로우 다이어그램.

도 12는 본 발명의 코어 기능을 사용하여 도구 데이터의 갱신 통지를 발행하기 위한 단계를 도시하는 플로우 다이어그램.

본 발명의 바람직한 실시예는 상이한 도구들 간의 부분 정보(part information)를 공유하기 위한 기준(base)을 제공하는 공통의 데이터 모델 프레임워크에서 구현된다. 프레임워크는 분할 작업 및 코드 생성을 지원하는 정보에 대한 공통 저장소(repository)와 개별 도구들에 의해 구축된 정보를 표준화하기 위한 모델 메카니즘을 결합한다. 상기 바람직한 실시예에서 구현되는 바와 같이 공통 저장소 구조의 예는 "A Hierachical Metadata Store for Integrated Development Environment"(IBM Docket No. CA9-97-003)라는 명칭의, 본 출원인의 카나다 특허 출원에 개시되어 있다. 본 명세서에서 본 발명의 바람직한 실시예를 충분히 이해하기 위하여 필요한 경우 공통 저장소에 대한 참조를 포함한다.

상기 논의된 바와 같이, 프레임워크의 원리는 도구 정보가 그 객체들 간의 다양한 클래스들 및 관계들의 모델 객체로 구성되어 있다는 점이다.

각 모델 객체는 이름, 속성의 세트 및 프레임워크 내 다른 모델 객체에 대한 참조를 포함하는 관계의 세트의 3가지 항목에 의해 특징지워진다. 모델 클래스 계층 구조는 도 1에서 개략적으로 도시된다. 도 2는 바람직한 실시예의 객체 추상 클래스에 대한 C++ 언어 인터페이스를 예시한다. 도 1 및 도 2를 참조하면, 객체 (1)과 관련된 정보는 객체의 이름 (2) 및 객체에 의해 설계된 객체의 속성의 이름 (3)과 같은 다수의 개별 문자열(string)로 정의된다. 각 속성 (3)은 표준 문자열 (3a) 또는 "blob" (3b)중 어느 하나의 값을 포함한다 ("blob"는 "2진 대형 객체(binary large object)"의 약자로 데이터 베이스 기술에 흔히 사용된다. 여기서는 바이트로 이루어지는 무정형 문자열을 지칭한다. 이것은 이하에서 상세히 기술된다).

도 4는 바람직한 실시예에 따른 blob 추상 클래스에 대한 C++ 언어 인터페이스를 도시한다. 너무 복잡하거나 고도로 구조화되어 문자열 형태로 표현될 수 없는 값은 일종의 blob로 구현될 수 있다. 모든 blob는 문자열에 의해 입력되는 데이터의 세그먼트를 설정하고 검사하기 위한 동작을 제공하여야 하는데, 이때 문자열의 해석은 전적으로 blob에 달려 있다.

바람직한 프레임워크 메카니즘의 또 다른 특징은 도 1 및 도 2에 도시된 모델 객체의 관계 (4)가 개별 클래스(class)로 정의되며, 상호 배타적인 고유한 이름을 갖는다. 도 3은 이하에서 속성 세트의 일부를 정의하는 바람직한 실시예의 관계 추상 클래스(relation abstract class)에 대한 C++ 언어 인터페이스를 도시한다.

도 1을 다시 참조하면 모델 객체의 모든 관계 (4)는 문자열인 이름 (5)로 특징지워 진다. 각 관계 (4)는 또한 다른 모델 객체에 대한 참조 (6)의 세트(0 또는 그 이상)를 포함한다. 관계 (4)는 그 관계의 이름을 검사하고 그 관계의 임의의 참조들을 추가, 검사 및 제거하기 위한 동작을 제공한다.

참조 (6)의 기능은 객체가 아직 메모리에 있지 않다면 디스크로부터 메모리로 모델 객체를 로드(load)하는 것이다. 참조들은 양방향이어야 한다. 하나의 객체가 제 2 객체를 참조하는 경우, 제 2 객체는 그 관계중 하나에 있어서, 제 1 객체에 대한 참조 회신을 포함한다. 또한 참조들은 강한(strong) 참조 또는 약한(weak) 참조 중 하나이다. 모델 객체 (1)이 삭제되었을 때에는 그 모델 객체 (1)이 강하게 참조하는 모든 모델 객체들도 또한 삭제된다. 반면에 다른 객체를 약하게 참조하는 객체가 삭제되었을 경우에는 그 다른 객체내의 삭제된 객체에 대한 양방향(bidirectional) 참조만이 삭제된다. 도 1에 예시된 2개의 상이한 메카니즘도 또한 정의되어야 한다. 검색 문맥(search context) (7) 및 로크 문맥이 존재하며, 로크 문맥은 3개의 특징, 즉 삭제 로크 (8), 리네임 (9), 변경 로크 (10)을 갖는다.

상이한 문맥으로 보일 수 있는 모델 객체는 그 모델을 통해 객체로 진행되는경로에 의존한다. 도 5는 바람직한 실시예에 따른 검색 문맥 추상 클래스에 대한 C++ 언어 인터페이스를 도시한다. 검색 문맥 (7)은 모델 내 객체의 서브세트를 따른 경로를 나타낸다. 검색 문맥은 속성을 발견(find) 및 검사(inspect)하기 위한 동작을 제공하며, 속성을 발견하도록 요구받았을 때 요구된 속성을 갖는 객체와 만날 때까지 또는 리스트의 끝 부분에 도달할 때까지 모델의 리스트를 따라 내비게이트한다. 만약 요구된 속성을 가진 객체가 발견되면 그 속성의 값은 복귀(return)된다. 따라서 상이한 검색 문맥은 모델 내의 단일 객체는 상이한 속성을 갖는 것으로 나타난다.

관계가 있는 모델 객체들은 도구에 의해 변화될 수 있기 전에 도구에 의해 로킹되어야 한다. 로킹은 프레임워크 계층 구조의 바람직한 실시예와 관련하여 이하에서 더욱 상세히 논의될 것이다. 모델 객체의 속성을 변화시키기 위해, 단지 객체 자신만이 로킹될 필요가 있다. 모델 객체를 리네임하기 위하여 객체 자신은 이름에의해 객체를 참조하는 모든 관계와 함께 로킹될 필요가 있다. 모델 객체를 삭제하기 위하여, 객체에 의해 직접 또는 간접적으로 강하게 참조된 객체 자신 및 임의의 객체들 뿐만 아니라 이 객체들을 참조하는 임의의 관계들이 로킹되어야만 한다. 각 관계 내의 각 객체는 독립적으로 로킹될 수 있으며, 이러한 기본 거동은 객체의 속성을 변경하는 것 만큼이나 간단히 동작시키기에 충분하다. 모델 프레임워크는 더 복잡한 리네임(rename) 및 삭제 시나리오를 핸들링(handle)하기 위한 로크 문맥 객체를 포함한다. 도 6은 삭제 로크 문맥 (8) 및 리네임 로크 문맥 (9)의 추상 클래스에 대한 C++ 언어 인터페이스를 도시한다.

리네임 로크 문맥은 객체를 리네임하기 전에 모델 객체로부터 구성될 수 있다. 다소의 관계들이 객체의 이름에 대한 키(key)가 될 수 있기 때문에, 리네임 로크 문맥은 개체에 대한 참조를 포함하는 임의의 관계 내의 모델 객체를 로크한다. 삭제 로크 문맥은 객체를 삭제하기 전에 모델로부터 구성될 수 있다. (프레임워크하에서, 이들 모델 객체들도 또한 삭제되기 때문에) 삭제 로크 문맥은 모델 객체 및 강한 참조 체인에 의해 도달할 수 있는 임의의 모델 객체를 로크하며, 상기 모든 객체에 대한 참조를 포함하는 임의의 관계를 로크할 것이다. 이들 참조는 쓸모없는(dangling) 참조를 하지 못하도록 관계로부터 제거되어야 한다.

추가적인 바람직한 구현 방법에 있어서, 객체 클래스들은 실제로 추상화 클래스(abstraction class) 및 구현 클래스(implementation class)로 이루어진 클래스의 쌍(pair)으로 되어있다. 이것은 도 7에 예시되어 있다. 모든 모델 객체는 대응하는 구현 객체 (14)에 대해 참조 (13)을 포함하는 추상화 객체 (11)을 포함한다.

객체에 대한 완전한 인터페이스 및 객체의 거동이 자신의 추상화 부분을 통하여 제공된다. 그러나 객체의 이름 (12)만이 실제로 그 추상화 부분에 저장된다. 객체의 속성 (15) 및 관계 (16)은 구현 부분 내에 은폐되어 있다. 자신의 이름을 초과하는 객체에 대한 임의의 정보의 요청은 구현 부분 및 아마도 그 구현 부분 내에 포함된 관계 중 일부에 의해 비밀리에 충족된다.

추상화, 구현 및 관계 객체가 독립적으로 지속되기 때문에, 객체의 이름에 대한 요구는 구현 부분이나 관계가 없이도 디스크 (17)로부터 추상화 부분을로딩(loading)하는 비용을 초래할 것이다. 이러한 기술은 조회(inquiry)를 만족시키며 프레임워크에 있어 도구들의 전체 성능을 향상시키기 위하여 디스크로부터 전송된 데이터의 양을 최소화한다.

상기 정의를 사용하여, 바람직한 실시예의 프레임워크는 개발 부분의 유연한 포함 계층 구조를 구현하기 위한 환경 및 지원 메카니즘을 제공한다. 기본 클래스(base class)들은 객체, 속성/특성 액세스, 실행 시간 형식의 식별 및 지속성 간의 (포함 지원(containment support)이라고 불리는) 부분 로킹 참조들에 대한 표준 거동을 정의한다. 모든 도구들은 기초 클래스로부터 구체적인 구현을 유도한다.

도 8은 본 발명의 바람직한 실시예에 따른 추상 기초 계층 구조를 도시한다. 이 계층 구조의 코어 기능은 점선 윗 부분의 상기 계층 구조 내의 기초 클래스로서 식별되는 지속성(Persistence) (20), 통지(Notification) (21), 로킹(Loking) (22)이다. 이것은 이들 클래스들 모두가 C++ 언어 프로그래밍 언어로 이루어질 수 있는 바와 같이 오버라이트될 수 없다는 것을 말하는 것은 아니지만, 지속성, 통지, 로킹의 일부 형식이 본 발명의 프레임워크가 동작되는데 필요한 코어 기능이다. IDE 요소 (24)로 시작하는 점선 아래의 클래스는 프레임워크 계층 구조에 포함될 수 있는 데이터 모델 형식의 일부를 도시한다. 이러한 추가적인 클래스들은 첨부된 부록에서 정의되며, 많은 추가 클래스들이 본 출원과 동시에 출원된 특허 출원(IBM Docket No. CA9-97-003)의 상세한 설명에서 설명된다.

본 발명의 프레임워크 계층 구조에 있어 승계(inheritance)는 이하의 형식을제공하도록 동작된다. 지속성 서비스(persistence service)는 호스트 컴퓨터의 파일 시스템 내의 상태를 유지하며 여러 가지 실행 프로그램들간에 이러한 데이터를 공유한다. 프레임워크 계층 구조로부터 유도된 모델 객체는 파일 시스템 내의 파일들로 분류(group)된다. 파일 시스템 내의 객체는 "위탁 모델(committed model)"이라고 지칭된다. 프레임워크 모델을 사용하는 프로그램을 실행할 때 위탁 모델 내의 데이터만을 볼 수 있다. 모델에 대한 모든 변화는 단일 실행 프로그램의 전용 주소 공간(private address space) 내의 모델 객체들의 내부 메모리 사본(copy)에 대해 수행된다.

로킹 서비스는 모델에 대한 갱신(modification)으로부터 상호 배타(mutual exclusion)를 실행한다. 각 실행 프로그램이 모델 객체의 전용 내부 메모리 사본에 대한 변경들을 생성하기 때문에, 두 개의 프로그램이 동일한 객체를 동시에 갱신 또는 삭제할 수 없다. 로킹 서비스는 동시 액세스를 금지하는 강제 로킹 방법을 제공한다. 이것은 이하에서 상세히 설명된다.

도 9를 참조하면, 모델 객체가 제공하는 지속성 기초 클래스 (20)으로부터의 승계는 각 프로그램의 디폴트 로컬 힙(default local heap)으로부터 구성되며 호스트 컴퓨터의 파일 시스템을 통하여 지속성에 의해 공유된다. 다수의 C++ 언어 구현 방법에 있어서, 동적 또는 실행 시간 바인딩은 통상 상수 방식 포인터들(constant method pointers)의 클래스-특정 테이블에 대한 각 객체 내의 포인터로서 구현된다. 방식 테이블 포인터들은 통상 동적 링크 라이브러리(dynamic link library) 또는 실행 가능한 프로그램에 저장되지만, 모든 실행 가능한 이미지들이 서로 상이하며 또한 테이블들의 위치가 다르기 때문에 액세스할 수 없다. 따라서, 보편적인 구현 방법에 있어서, 공유된 메모리 내의 C++ 언어 객체를 저장하는 것이 불가능하며 상이한 실행 가능한 이미지들로부터 그 객체의 데이터를 액세스하는 것도 불가능하다.

본 발명의 지속성 서비스는 디폴트 로컬 힙 구성(default local heap construction)을 통하여 이러한 문제점을 피한다.

또한, 지속성 클래스 (20)은 디스크에 기록하고 디스크로부터 판독하기 위한 프레임워크 내의 모든 클래스에 메카니즘을 제공한다. 기본 객체 상태를 확장하는 모델 내의 모든 유도된 클래스는 자신의 "판독" 및 "기록" 방식을 제공해야 하지만, 지속성 클래스는 또한 클래스가 객체의 디스크 형식 및 내부 메모리 형식 간의 변환에 사용되는 스트리밍 연산자(streaming operator)를 무시하도록 객체 스트리밍에 대한 메카니즘을 정의한다. 스트리밍 연산자들은 실제 처리(processing)를 수행하기 위한 각 객체의 자체 "판독" 및 "기록" 방식을 실행한다. 이하의 구현 규칙(convention)은 바람직한 실시예의 도출된 클래스에 대해 "판독" 및 "기록" 방식을 정의함에 있어 모든 클래스에 사용된다.

바람직한 실시예에 있어서, 프레임워크는 C++ 언어 객체에 대해 강제 상호 배타를 구현하기 위한 표준 인터페이스를 제공한다. 이러한 구현 방법을 사용하는 클래스는 로킹 클래스 (22)로부터 도출된다. 상호 배타가 실행 프로그램 간에 공유된 객체에 대해서만 요구되기 때문에 로킹 (22)는 그 자체로 지속성 (20)의 서브 클래스이다.

로킹 (22)에 의해 제공되는 로킹 방법이 이하에서 설명된다. 그러나, 이러한 메카니즘이 부적당한 2가지 경우가 존재한다: 첫째, 특정 형식의 모든 객체를 포함하도록 보증된 데이터 구조체(data structure)인 "부분들"의 전체 리스트(global parts list)의 경우; 둘째, 모델 객체와 함께 저장되어 있지만 그 모델 객체의 부분이 아닌 갱신된 메타 정보에 대한 메카니즘인 더티 풀(dirty pool)의 경우.

로킹 클래스 (22)는 로킹될 수 있는 지속성 객체(persistent object)에 대한 모델 추상화(model abstraction)이다. 로킹 클래스 (22)는 모델 내에서 사용되는 로킹 프리미티브들(primitives)을 제공한다. 일반적으로, 이들 프리미티브는 직접 사용되는 것이 아니라 합성 객체 로크(composite object lock)의 일부로서 호출된다. 객체 로크는 2단계로 구성된다;

1. 계획된 형식의 동작을 위해 로크 식별자가 획득된다. 바람직한 실시예에 서, 로크 풀(lock pool)은 이하에서 기술되는 바와 같이 고정된 크기의 이름이 지정된 공유 메모리 세그먼트를 조작하는 스케일 가능한 공유 메모리 풀(scalable shared memory pool) 내에 위치된 단독(singleton) C++ 언어 클래스이다. 이 때문에 로크 식별자는 풀 내로의 실제 배열 인덱스이다.

2. 공유 로크 또는 배타 로크는 획득된 로크 식별자를 사용하여 로크 객체 형식을 실현(instantiate)함으로써 구성된다. 바람직한 실시예에서, 로크는 코드 블록이 빠져 나간다 할지라도 파괴자(destructor)가 자동으로 실행되도록 통상 로컬 인스턴스(local instance)로서 사용되는 C++ 언어 구성자(constructor)의 방법으로 획득된다. 로크 획득 실패(failure)는 예외를 통해 전달된다. 파괴자는 대다수의 경우에 로크를 프리 업(free up)하는데, 하나의 예외는 갱신 로크 문맥일 경우이다.

단독 클래스는 매 프로세스 당 한번씩 살아 있는 단 한가지 클래스 인스턴스가 될 수 있는 C++ 언어 프로그래밍 규칙을 참조한다.

도구 데이터 모델 객체 자신들과는 별도로 로크 객체용 저장소로서 스케일 가능한 공유 메모리 풀을 사용하는 것은 "Locking Tool Data Object in Framework Environment"라는 명칭으로 본 발명과 동시 출원된 IBM Docket No. CA9-97-010에 개시되어 있다.

스케일 가능한 공유 메모리 풀은 시스템의 이름이 지정된 공유 메모리 풀로부터 고정 크기의 세그먼트를 할당하는 것을 포함하는 피어 투 피어(peer to peer) 풀링(pooling) 메카니즘이다. 세그먼트의 이름은 미리 정의된 문자 순서를 취한 후 세그먼트 번호(0에서 시작)를 부여함으로써 생성된다. 각 프로세스는 그 프로세스에 대한 풀 세그먼트를 조작하는 단독 풀을 가진다. 새로운 세그먼트가 요구될 경우 이름이 계산되고 현재 메모리 내의 세그먼트를 발견하기 위한 시도가 이루어진다. 현재 메모리 내의 세그먼트가 발견되지 않으면 그 세그먼트가 할당된다. 이러한 프로세스는 상기 메모리 세그먼트를 요구하는 제 1 프로세스는 그 세그먼트를 할당하고 모든 후속 프로세스(subsequent process)는 그 세그먼트를 다시 액세스하도록 동기화(synchronized)된다(클라이언트/서버와 반대 개념인 피어 투 피어 방식). 프로세스 내의 각각의 단독 풀 클래스는 자신이 알고있는 모든 세그먼트의 배열을 유지한다. 이것은 배열 내로의 신속한 우회 방법(indirection)으로서 프로세스 내의 임의의 세그먼트에 대해 액세스를 허가한다. 세그먼트의 배열 이외에도, 풀에 대한 전체 정보를 포함하는 이름이 지정된 특정 영역이 할당된다. 이러한 영역의 이름은 고정되어 있으며 자신의 풀을 시작하기 위한 제 1 프로세스가 그 영역을 할당한다. 풀 내의 전체 정보에 대한 액세스는 두 개 이상의 프로세스들 간의 경쟁 상태(race condition)를 회피하도록 동기화된다.

각 세그먼트는 고정된 크기의 객체 배열로 취급되어 크기가 "x"인 "n"개의 조각으로 분할된다(여기서 "x"는 풀에 놓여진 객체의 크기이다). 각 프로세스가 한 조각의 기억장치를 필요로 할 경우, 풀 id의 획득을 요구한다. 풀은 할당된 현재 가장 높은 인덱스를 발견하기 위해 전체 정보 세그먼트를 사용한다. 다음번 높은 인덱스 값이 세그먼트 내에 아직 존재할 경우(즉, n의 배수가 아닐 경우), 그것은 간단히 복귀된다. 그렇지 않으면, 사용되지 않는 객체를 발견하기 위하여 현재 풀 내에 있는 모든 객체에 대한 검사(check)가 행해진다. 단독 클래스가 이러한 검사를 수행할 수 있도록 풀 세그먼트 내의 "n" 조각의 기억 장치의 각각은 그것이 사용되는지의 여부를 표시하기 위한 표시기를 가져야 한다. 사용되지 않은 객체가 발견되면, 그 인덱스는 뒤로 전달되며 기억 장치는 사용된 것으로 표시되고, 그렇지 않으면 새로운 세그먼트가 할당된다.

일단 인덱스가 분배되면 그 인덱스는 특정 풀 방법을 통해 공유 메모리 기억 장치를 액세스하는데 사용될 수 있다. 풀 방법은 간단하게 인덱스를 취하여 세그먼트 내의 세그먼트 번호 및 인덱스를 계산한다. 그 다음 세그먼트 주소의 배열을 액세스한 후 세그먼트 내 객체의 주소를 계산한다. 이러한 방식으로 공유 메모리가Windows^TMNT와 같은 소정의 플랫폼들(platforms)에 대한 경우인 상이한 가상 주소에 할당될 수 있다 하더라도 동일 id는 다중 프로세스에 의해 사용될 수 있다. 계산식은 아래와 같다:

세그먼트 번호 = 풀Id / n

세그먼트 인덱스 = 풀Id 계수 n

풀은 필요한 경우 세그먼트를 할당하기 때문에 스케일 가능하다. 이러한 풀은 피어 투 피어 방식으로, 이러한 방식에서는 얼마나 많은 프로세스들이 포함되어 있는 지, 또는 이들 프로세스들이 어떤 순서로 시작되는지 문제가 되지 않는다(서버가 필요하지 않다). 메카니즘은 자신의 id에 의해 임의의 항목(item)을 액세스하기 위한 두 개의 우회 방법(indirection)만을 필요로 한다.

본 발명의 바람직한 실시예에서, 로크 객체 형식은 아래와 같다.

1. 공유 로크: 공유 판독 전용 액세스

2. 배타 로크: 하나의 프로세스에 대한 판독/기록 액세스를 제한한다.

도 9의 상태 다이어그램에 도시된 바와 같이, 로크 객체를 구성하면 기본적인 로크 가능 모델 객체에 대한 액세스를 로킹한다. 대다수 경우, 로크 객체의 파괴는 액세스를 로크 해제하는데 필요하다. 따라서, 공유 로크 형식의 실현(instantiation)을 제거하기 위해 삭제 로크 형식을 실현함으로써 기본적인 모델 객체에 대한 공유 제한 판독/기록 액세스는 복구된다. 이것은 객체가 삭제되지 않으며 다른 것들이 그 객체를 판독 또는 갱신하도록 하는 것(즉, 공유 또는 배타 갱신 로크를 획득하는 것)을 보장한다. 예외는 로킹된 기본적인 객체가 갱신되는경우이다. 로크는 갱신이 저장될 경우에 파괴될 수 있다.

구성 및 파괴에 대한 강제 로킹은 규칙을 통해 실행된다. 프레임워크 클래스들의 구성자 및 파괴자는 "보호(protected)"이다. 이것은 프로그램이 객체를 직접 생성 또는 삭제하는 것을 방지한다. 대신에, 클래스 데이터의 "생성" 및 "파괴" 방법이 모든 프레임워크 클래스에 제공된다. 상기 생성 방법은 객체를 구성하기 전에 객체를 생성하여 기존 모델 내로 삽입하는데 필요한 로크를 획득한다. 상기 파괴 방법은 객체를 삭제하기 전에 모델로부터 객체에 대한 모든 참조를 제거하는데 필요한 모든 로크를 획득한다. 로크 획득 실패의 결과 취소된 갱신 동작이 중단되고, 모델 상태가 불변이며, 그리고 예외는 폐기된다.

로크의 수명은 지속성 서브시스템 및 메모리 내의 로크를 참조하는 로크 객체의 존재 모두에 좌우된다. 이것은 도 10에 도시되어 있다. 로크 객체 클래스 (100)은 그 파생물로 공유 로크 (102) 및 배타 로크 (104)를 가진다. 이들 간의 차이점은 공유 로크가 다수의 프로세스를 가질 수 있는 반면 배타 로크는 동시에 하나의 프로세스에 대해서만 가능한 "배타적"이라는 점이다. 단일 프로세스 자원은 그 프로세스에 대해 하나의 배타 로크 또는 하나 이상의 공유 로크를 가질 수 있다.

로크 객체 (100)이 로크 가능한 객체 (106)에 의해 실현되는 경우, 로크는 로크 가능한 객체가 구성될 때 할당된 로크 ID를 통해 로크 풀 (108)을 참조함으로써 위치가 설정된다. 로크 풀 내의 로크 (112)는 로크 소유자 (116)의 프로세스 ID를 포함한다. 로크 소유자가 이미 소유하고 있는 로크를 재획득하려는 시도도 허용된다.

공유 로크의 경우에 있어서, 프로세스 ID는 항상 모조(dummy) 또는 예약된 식별자이다. 동일한 모조 식별자는 공유 로크를 획득하려는 모든 시도에 의해 사용된다. 따라서, 공유 로크가 이미 임의의 프로세스에 의해 보유되는 경우 프로세스 ID가 일치(match)되어 로크가 부여된다. 수많은 공유 로크 소유자들을 추적하기 위하여, 참조 카운터가 사용된다. 참조 카운터는 로크가 획득될 때마다 증가되며 로크가 해제될 때마다 감소된다. 카운터가 0에 도달하면 로크는 어느 프로세스에 의해서도 더 이상 소유되지 않으며 공유 또는 배타 로크 중 어느 하나로서 사용될 수 있다.

배타 로크의 경우에 있어서, 공유를 방지하기 위하여 실제 프로세스 ID가 사용된다. 특정 형식의 배타 로크는 로킹된 객체의 갱신 상태를 추적하는 "갱신(modify)" 로크이다. 객체가 갱신되지 않을 경우, 로크는 자신의 파괴자가 실행될 때 즉시 자유롭게 된다. 로킹된 객체가 갱신되는 경우, 갱신 로크는 로킹된 객체에 대한 모든 변화가 저장에 의해 위임되거나 또는 모든 변화가 취소될 때까지 갱신 로크 파괴자에 의해 해제되지 않는다. (저장이 수행됨에도 불구하고) 갱신 로크가 파괴되지 않는 경우, 객체는 로킹된 상태를 유지한다. 프로그램은 저장을 통해 로킹된 객체를 유지하기 위하여 상기 거동에 좌우될 수 있다.

두 개의 예외가 로킹 메카니즘, 부분들의 전체 리스트 및 "더티 풀(dirty pool)"의 사용을 위해 상기에서 설명된 바 있다.

부분들의 전체 리스트는 지정된 유일 객체의 세트를 포함한다. 바람직한 실시예의 프레임워크에 있어서, 이것은 단독 클래스인 단일 객체 내에 포함된다. 이름이 충돌(name clashes)하는 것을 검출하는 데이터 구조를 포함하는 공유 메모리 리스트가 구현될 경우, 하나의 부분(part)이 하나의 프로그램 내의 전체 리스트에 추가되며 그 부분의 이름은 위임된 부분들의 리스트 및 위임되지 않은 부분들의 이름의 공유 리스트 모두에서 유일성에 대한 검사가 이루어진다. 이름이 유일하지 않은 경우, 추가 동작이 실패하고 예외 상황이 폐기된다. 그렇지 않으면, 삽입 동작이 완료되며, 이름은 다른 프로그램이 그 이름을 사용하지 못하도록 공유 힙에 추가된다. 각 실행 프로그램은 삽입된 객체의 리스트를 유지한다. 저장 동작이 진행 중일 때 프로그램은 이러한 모든 객체를 제거한다. 이름만을 저장함으로써, 부분의 전체 그룹 내의 이름 충돌을 방지하는데 사용되는 공유 메모리의 양이 최소화되는 스케일 능력(scalability)이 제공된다.

제 2 예외 상황은 더티 풀(dirty pool)이다. 이것은 소스 코드 파일에 대응하는 갱신(update)이 없이 객체가 갱신되었는지의 여부를 추적(track)하는 인덱스 풀(index pool)을 참조한다. 객체의 종속성(dependencies)이 변경될 경우, 객체는 재생되어야 한다. 실제 객체를 갱신하지 않는 것은 성능 향상 뿐만 아니라 프로세스들 간의 로크 경쟁(lock contention)을 감소시킨다. 객체 및 객체의 원시 파일(source file)의 동시성(concurrence)이 결여된 경우, 객체는 "오염(tainted)" 또는 "더티(dirty)"와 같은 인덱스 풀에 대한 이름으로 참조된다. 더티 풀은 공유 객체에 대한 원격 데이터를 지원하기 위한 스케일 가능한(scalable) 공유 메모리 풀 메카니즘을 사용한다. 원격 데이터는 객체에 의존하지 않는밀봉된(encapsulated) 객체 상태이다. 이 데이터는 객체의 로크, 객체의 갱신, 객체 순서의 저장을 거치지 않고 갱신되어 프로세스들 간의 로크 경쟁(lock contention)의 필요성을 감소시킬 수 있다. 풀은 로크 풀 인덱싱 방법을 사용하며, 하나의 객체에는 모델 객체의 수명이 영구적인 더티 풀 인덱스 내의 비트 세그먼트인 하나의 식별자가 할당된다. 각 더티 풀 세그먼트는 반으로 분할된다. 첫 번째 절반은 내부-사용 비트를 가지며 두 번째 절반은 더티 상태 비트를 가진다. 풀은 바람직한 실시예에서 지속성을 갖는다. 더티 풀은 디스크와 양방향으로 자신을 스트림(stream)한다. 이러한 방법에 있어서, 객체에 대한 소스가 재생될 필요가 있는지의 여부에 관한 정보가 후속 세션들(subsequnet sessions) 내에서 조회(query)될 수 있다.

모델에 대한 변경을 실행할 때, 지속성 서비스에 대한 3개의 요건이 존재한다.

1. 프로그램은 실행된 모델로부터 동작하는 동안 기존(old) 객체의 새로운 버젼을 판독할 수 없다.

2. 파일에 대한 변경 기록의 완료를 실패(failure)하면 실행된 모델을 변조(corrupt)할 수 없다.

3. 하나의 프로그램 내에서 행해진 변경은 다른 프로그램에 의해 실행된 변경을 오버라이트할 수 없다.

저장은 내부적으로 프로세싱된 통신 프로토콜(interprocessed communication protocol)에 의해 동기화되는 파일 시스템 내로의 2 단계 실행으로서 구현된다. 이러한 프로세스가 도 1 의 순서도에 도시되어 있다. 내부 프로세스 통신 프로토콜은 "저장 대기(save pending)" 및 "저장 완료(save complete)"의 2개의 이벤트(events)를 사용한다. 이들 이벤트들은 공유 메모리 플래그(shared memory flag), 공유 메모리 카운터, 및 통지(notify) 및 승인(acknowledge)으로 불리우는 두 개의 호스트 시스템 세마포어들(semaphore)로 구현된다.

저장 프로그램이 "저장 대기(save pending)" 이벤트를 전송할 경우(블록 40), 저장이 시작된다. 이벤트를 전송하는 것은 이벤트 공유 메모리 플래그를 참(true)으로 세팅하는 단계, 모델에 접속된 많은 프로그램 수에 대한 모델 공유 메모리 카운트(count)를 초기화하는 단계, "승인(acknowledge)" 세마포어를 리셋(reset)하는 단계, 및 통지(notify)를 포스트(post)하는 단계로 이루어진다.

플래그 파일이 저장의 1 단계가 시작되었음을 표시할 경우, 저장 프로그램은 임시 파일로 갱신되었던 모든 파일을 기록한다(블록 44). 임시 파일들이 아직 모델을 활성 상태로 사용하고 있을 경우, 임시 파일에 저장하는 것은 다른 프로그램이 임시 파일을 액세스하는 것을 방지한다. 이것은 안전 저장 목표의 제 1 부분의 절반을 만족시켜 다른 프로그램은 실행된 모델로부터의 객체들을 임시 파일 내의 객체들과 혼합할 수 없다.

저장 프로그램이 임시 파일에 모든 변경된 파일들을 기록하는 것을 일단 완료하면(블록 46), 그 저장 프로그램은 "저장 대기(save pending)" 이벤트가 완료되기를 기다린다(블록 48). 이것은 "승인(acknowledge)" 세마포어가 포스트될 경우, 전송 프로그램에 대해 승인된다.

저장 중(save pednding) 이벤트는 프레임워크 모델에 부착된(attached) 각 프로그램 내에서 발견되는 작업자 스레드(worker thread)에 의해 처리된다(porcessed). 이벤트가 수신될 경우, 작업자 스레드가 웨이크업(wake up)된다. 스레드는 프로그램 내에 오픈된 모든 모델들을 저장 플래그 세트를 가진 모델과 비교함으로써 저장되는 모델에 프로그램이 부착되어 있는지의 여부를 결정한다. 프로그램이 저장 모델에 부착되어 있는 경우, 교차 스레드 패키지는 통지(notification)를 프로그램 메인 스레드에 포스트(post)하기 위하여 사용된다. 이러한 통지는 메인 스레드가 모든 GUI 이벤트들 및 저장된 대기 통지(saved pending notification) 이전에 수신된 통지들의 처리를 완료한 후에 비동기식으로 수신된다(블록 58).

프로그램 메인 스레드가 동일한 대기 통지를 수신한 경우, 그것은 모델 내의 요구-로딩(demand-loading) 및 변경(changing)을 중지시킨다(블록 60). 이것은 상기 요건 1을 완료하며, 프로그램은 기존 객체들 및 새로운 객체들을 혼합할 수 없다.

다른 프로그램들이 저장 대기 이벤트를 수신하면, 공유 메모리 카운터를 감소시켜 이벤트의 수신을 인식(acknowledge)한다(블록 62). 감소 카운터가 1일 경우, 모든 프로그램들이 "통지(notify)"를 처리(process)했으며 "인식(acknowledge)" 세마포어 이벤트가 포스트(post)되어 이러한 이벤트가 완료되었음을 표시하여(블록 64) 전송 프로그램을 웨이크업한다(블록 48).

"저장 대기(save pending)" 이벤트가 완료될 경우, 저장 프로그램은 저장 완료의 제 1 단계(first phase)를 디스크 플래그 파일들을 통해 플래그한다(블록 46). 이러한 시점 이전에 시스템 충돌과 같은 인터럽션은 모든 변경을 상실하지만 데이터베이스를 일관된 상태로 남겨둔다.

에러가 발생하지 않으면, 모델의 변경 버전을 액세스하는데 필요한 모든 데이터는 디스크에 기록되며 시스템 또는 프로그램 충돌(crash)이 디스크-상 모델(on-disk model)을 일관되지 않은 상태로 남아 있도록 하는 것이 불가능하다. 그 다음, 저장 프로그램은 모든 임시 파일을 적절한 이름으로 리네임하고, 실행된 모델로부터 비어있는 모든 데이터 파일을 제거한다(블록 50). 이것은 변경된 모든 파일들이 자신들의 내용을 임시 파일 내의 버전들로 대치시켰음을 의미하며, 이것은 안전 저장의 제 2 요건을 만족시킨다.

저장 프로그램은 다른 모든 프로그램들에 대해 디스크 상 모델이 일관된 상태임을 표시하기 위하여 "저장 완료(save complete)" 이벤트를 대기 작업자 스레드 및 프로그램 메인 스레드로 전송하며(블록 52), 클린업(clean up) 단계(블록 56)을 수행하기 전에 이벤트가 완료되기를 대기한다(블록 54).

도 8의 통지 기초 클래스(Notification base class) (21)에서 발견된 다른 코어 기능은 다른 유저들에게 프레임워크 내의 도구 데이터의 변경을 통신하기 위한 메카니즘을 제공한다. 이것은 또한 도 11에 도시된다.

모델에 접속된 모든 프로그램들이 "저장 완료(save complete)" 이벤트를 수신하는 경우(블록 64), 웨이크업된다(wake up). 그 다음, 이 프로그램들은 각 변경된 객체의 최신 리비젼을 오픈하여 로드하는 각 파일 프로그램을 방문하는 프레임워크 재생 방법을 호출한다(블록 66). 이 프로세스가 일단 완료되면, 모든 프로그램은 가장 최근에 저장된 변경과 일치하는 모델의 전용(private) 내부 메모리 버전을 포함한다. 프로그램이 저장 프로그램에 의해 삭제 및 변경되었던 임의의 객체를 포함하는 경우, "저장 완료(save complete)" 이벤트를 수신하는 프로그램은 또한 영향을 받은 객체들의 모든 관찰자(observer)에게 전송된 모델/뷰/제어기 통지를 가진다(블록 68). 이러한 통지를 관찰하는 것은 프로그램이 모델에 대해 실행된 변경과 일치하는 내부 상태를 만들기 위해 사용하는 후크(hook)이다. 재생을 수행한 후에, 각 프로그램은 저장 완료 이벤트의 수신을 인식한다(블록 70).

저장 완료 이벤트를 완료하면 저장 프로그램 및 모든 작업자 스레드를 웨이크업한다. 저장 프로그램은 나머지 하우스키핑 작업을 완료하고 저장으로부터 복귀된다. 작업자 스레드는 저장 대기 내부 프로세스 이벤트(save pending interprocess event) 상에 대기 상태로 복귀한다.

많은 모델 객체를 변경하는 동작이 성공적으로 완료될 것인지의 여부를 미리 결정하는 것이 항상 불가능한 것은 아니기 때문에, 본 발명의 추가적인 실시예에서 지속성 서비스는 실패 이벤트 내의 공지된 양호한 상태(good state)로 복귀하기 위한 능력을 제공한다. 이 프로세스는 도 12에 도시된다.

검사 포인트 메카니즘은 프로그램의 전용 내부 메모리 상태를 재저장한다. 저장될 상태는 객체 및 데이터 파일들을 관리하기 위해 사용된 지속성 서비스 데이터 구조들뿐만 아니라 프로그램이 시작 또는 모델을 저장한 이후에 발생했던 모든 객체의 삭제, 생성 및 갱신을 포함한다. 검사 포인트 메카니즘이 동작하고 있는 동안, 이러한 데이터는 임시 파일에 보존된다.

프로그램은 이전 상태의 재저장을 요구할 수 있는 갱신의 시작을 표시하는 검사 포인트 메카니즘을 호출한다(블록 76). 그 다음, 지속성 서브시스템은 모델 상의 각 프로그램에 의해 오픈된 각 지속성 파일을 방문한다. 지속성 서브 시스템은 내부 메모리 상태가 실행된 상태와 다른 객체들을 식별한다(블록 78). 메모리에서는 갱신된 객체가 임시 파일로 저장됨으로써 플래그된다(블록 80, 82).

시도된 갱신이 성공적이지 않을 경우, 통상 예외 상황이 폐기 및 포착되기 때문에 "롤 백(roll back)" 방법이 호출된다(블록 88). 롤 백 방법은 검사 포인트 후에 삭제된 객체를 재생성하며, 검사 포인트 이후에 생성된 객체를 제거하고, 검사 포인트가 호출될 때 모든 갱신된 객체의 상태 및 그 객체들의 상태에 대한 지속성 서비스 데이터 구조의 상태를 재저장한다(블록 90).

프로세스가 알고리즘이 성공적으로 완료되었다고 결정하는 경우(블록 84, 86), 그것은 검사 포인트 메카니즘에 의해 사용된 자원들을 해제(release)하며 내부 모델 상태를 일관된 것으로 플래그하기 위한 "실행(commit)"을 호출한다.

당업자에 대해 자명한 본 발명의 상기 바람직한 실시예에 대한 변경은 첨부된 특허 청구 범위 내에 포함된다.

도구(tool) 데이터와 같은 데이터가 일반적으로 액세스 가능할 경우, 동시 유저 프로세스들(concurrent user processes)이 중복 갱신(overlapping modification)을 만들며 불완전 또는 불가해(incomprehensible) 상태의 데이터를남기는 위험이 존재한다. 본 발명은 이를 방지하기 위한 로킹 메카니즘(locking mechanism)을 제공한다.

Claims (4)

1. 애플리케이션 개발 환경에서 공통 도구 액세스(common tool acess)를 위한 데이터 객체 로킹 메카니즘(mechanism for locking data objects)에 있어서,

   a) 자체 프로세스(owning process)의 상태가 사용 상태(occupied)인지 또는 자유 상태(free state)인지를 표시하기 위한 표시기(indicator)를 가지는 로크 객체들(lock objects)을 포함하는 저장소(repository); 및

   b) 데이터 객체들로부터 상기 로크 객체들을 참조하기(referencing) 위한 수단을 포함하며,

   상기 로크 객체들은,

   ⓐ 다수의 프로세스들이 소유하는 공유 로크들(shareable locks) - 공유 로크 각각은 그 자신의 상태를 지정하기 위한 표시기를 갖고 있음 -; 및

   ⓑ 어떤 하나의 프로세스만이 소유하는 배타 로크들(exclusive locks) - 배타 로크 각각은 그 자신의 상태를 지정하기 위한 표시기를 갖고 있음 -

   을 포함하며,

   상기 공유 로크 각각의 상기 표시기는 예약 프로세스 식별자(reserved process identifier)를 포함하며,

   상기 배타 로크 각각의 상기 표시기는 자체 프로세스의 프로세스 식별자를 포함하는

   데이터 객체 로킹 메카니즘.
2. 제1항에 있어서,

   로크 객체들을 파괴하기(destructing) 위한 수단을 추가로 포함하되,

   상기 로크 객체 파괴 수단은, 배타 로크의 경우에,

   a) 상기 배타 로크로부터 참조된 데이터 객체가 갱신되었는 지의 여부를 결정하기 위한 수단; 및

   b) 상기 데이터 객체에 대한 임의의 갱신이 저장될 때까지 로크 파괴를 지연시키기 위한 수단

   을 포함하는

   데이터 객체 로킹 메카니즘.
3. 제1항에 있어서,

   배타 로크들이 명백히 파괴되지 않았을 경우 저장(save)을 통해 지속하는 데이터 객체 로킹 메카니즘.
4. 제1항에 있어서,

   자유 상태에 있는 로크 객체가 공유 로크 또는 배타 로크 중 어느 하나로서 자체 프로세스에 의해 사용될 수 있는 데이터 객체 로킹 메카니즘.