KR101623631B1 - 캐시 메모리 구조 및 방법 - Google Patents

Abstract

본 발명은 캐시 메모리 및 데이터 액세스 제어 방법에 관한 것이다. 본 발명에 따르면, 데이터 영역(410)과 분리되어 형성되는 것이 유리한 제어 영역이 캐시에 저장된 데이터로의 액세스를 제어하기 위해 구비되고 이를 응용 프로세스가 읽는다. 제어 영역에는 옵셋(442)과 데이터 버전 정의 섹션(452, 454, 456)을 갖는 적어도 하나의 릴리스 영역(430)이 포함된다. 클라이언트/서버 구조의 공유 메모리에 적용된다.

Description

캐시 메모리 구조 및 방법 {CACHE MEMORY STRUCTURE AND METHOD}

본 발명은 일반적으로 데이터 처리 분야에 관련된 것으로서, 특히, 데이터 캐시 파일이 마스터 데이터베이스로부터 다수의 미들웨어 처리 노드에 분산되는 분산 클라이언트/서버 소프트웨어 아키텍처에 관한 것이다. 보다 더 구체적으로, 본 발명은, 분산된 캐시 파일들을 활용하는 특히 미들웨어 응용(applicative) 프로세스를 위하여 이 분산된 캐시 파일들의 버전을 계속적으로 제어하는 방법 및 시스템에 관한 것이다.

1980년대 후반에 등장한 클라이언트/서버 모델은, 그 당시의 표준이었던 중앙집중식, 메인프레임, 시간 공유 컴퓨팅과 비교할 때, 사용성, 유연성, 상호 운용성, 및 확장성이 개선된 다목적의 모듈식 소프트웨어 아키텍처이다. 이후 클라이언트/서버 아키텍처는, 모든 정보가 중앙 호스트 컴퓨터 내에 있고 사용자는 단순 단말기를 통해 이 호스트와 인터랙션하던 기존의 메인프레임 소프트웨어 아키텍처를 점진적으로 대체해 왔다. 그러나 메인프레임이 여전히 사용중에 있다면, 그것은 서버로부터 수신되고 서버로 전송되는 데이터를 스스로 처리할 수 있는 지능적인 그래픽 유저인터페이스(GUI)에 의해 단순 단말기가 대체된, 다양한 클라이언트/서버 아키텍처에서 강력한 서버로서 사용되고 있는 것이다.

현재의 데이터 처리 시스템에서, 널리 사용되며 원격지에 위치한 다수의 클라이언트를 지원할 수 있는 클라이언트/서버 아키텍처는 소위 3 계층(3 tier) 아키텍처이다. 이러한 아키텍처의 예는 도 1에 나와 있다. 데이터 계층(100)은 전통적으로 마스터 데이터베이스 시스템(120)의 주위에 구성되는데, 이는 아마도, 상업적 및 행정적으로 운영되는 모든 종류의 업무를 수행하기 위해 임의의 비즈니스 조직, 회사, 또는 기업의 일상 운영에 필요한 모든 데이터가 저장되는 대형 또는 초대형 저장소이다. 데이터베이스는 대부분 관계형이다. 즉, 관계형 데이터베이스 관리 시스템(RDBMS)에 의해 제어된다. 이것은 일반적으로, GUI(140)에서 데이터 처리 시스템의 관리자가 하나 이상의 마스터 서버(112)를 통해 관리한다. 관리자는 일반적으로 직접 데이터베이스 내용을 업데이트할 수 있는 권한을 부여받은 시스템내 유일한 사용자이다.

도 1의 예시적 3 계층 시스템의 중간 계층은 애플리케이션 계층(200)인데, 이로부터 조직(데이터 처리 시스템의 소유자)의 모든 특정 소프트웨어 애플리케이션(240)이 실행된다. 이러한 특정 애플리케이션들의 집합(일반적으로 미들웨어 소프트웨어라고 지칭됨)은 해당 조직의 독점적 재산인 소프트웨어이다. 이것은 마스터 서버(110)를 통해서 그 데이터 저장소(120)로부터, 그 조직의 모든 원격지 클라이언트(120)에 서비스를 제공하는 데 사용된다. 원격지 클라이언트는 3 계층 아키텍처의 세 번째 계층(300)을 구성한다. 따라서, 클라이언트 계층(300)으로부터의 질의(query)는 중간 계층(200)의 특정 애플리케이션에 의해서 데이터 계층(100)에서 불러온 데이터에 대해 처리되고 응답된다.

3 계층 아키텍처에서, 상대적으로 많은 수의 원격지 클라이언트에 서비스를 해야 할 때에, 전체적 성능을 유지하기 위한 시스템의 확장성은 독립 처리 노드를 중간 계층에 추가하여 얻을 수 있고, 이로써 데이터 처리 시스템의 전반적인 처리 능력을 증진할 수 있다. 따라서, 애플리케이션 계층(200)은 일반적으로 여러 개의 독립 처리 노드들로 구성된다. 이들 노드들은 아래의 설명에서와 같이, 슬레이브 노드(210)라고 한다. 많은 슬레이브 노드로부터의 너무 많은 데이터 요청에 의해 데이터 계층(100)이 압도당하는 것을 방지하기 위한 일반적인 실무 관행은, 마스터 데이터베이스로부터 가져오고 그리고 필요한 만큼 각 애플리케이션 노드에 저장되는 데이터에 대해 수행되는 응용 프로세스(applicative process)(240)를 사용하는 것이다. 도 1의 예시 시스템에서 이는 캐시 파일(250)의 형태를 취하는데, 응용 프로세스(240)들은 마스터 서버를 통해 마스터 데이터베이스로부터 캐시 파일들을 필요할 때마다 가져오는 데 긴 시간 지연을 일으키지 않고 실행될 수 있다. 따라서 이러한 데이터 처리 시스템에서, 처리 능력과 소프트웨어 애플리케이션은 시스템의 모든 원격지 클라이언트(300)를 서비스하는 데 필요한 처리 능력의 수준에 도달하기에 필요한 만큼의 노드(210)로 분산(즉, 복제)된다. 캐시 파일(250)도 이와 같이 분산된다. 각 노드에서 캐시 파일(250)은 일반적으로, 노드에서 실행중인 모든 응용 프로세스(240)들 사이에서 공유된다. 이를 위해, 캐시 파일은, 마스터 데이터베이스로부터 온 데이터에 대해 응용 프로세스가 실행되기 위하여 모든 응용 프로세스가 이 데이터에 빠르게 액세스(access)하도록 하기 위해서, 메모리맵 파일(memory-mapped file) 형태로 공유 메모리(230)에 저장된다.

슬레이브 노드 운영 체제(operating system)에서는 메모리맵 파일의 생성시에 그 크기가 부여된다. 따라서, 파일 크기는 캐시 파일의 전체 수명 동안에 동일하게 유지된다. 도 2 에서 보는 바와 같이, 메모리맵 파일(10)로서 실현되는 캐시 파일(250)은 두 부분으로 구성되는데, 첫 번째 부분은 메모리맵 파일의 모든 응용 데이터 컨텐트를 저장하는 데이터 영역(20)이고, 두 번째 부분은 제어 데이터를 보관하는 제어 영역(30)이다. 데이터 영역은 추가적으로, 두 부분의 연결된 데이터블록 리스트로 나뉜다. 연결 리스트 중의 하나(23)는 비활성(inactive) 데이터블록(24)의 형태로 이전 단계의 데이터(즉, 과거 데이터)를 보유한다. 다른 연결 리스트(21)는 활성(active) 데이터블록(22)의 형태로 현재 단계의 데이터를 저장한다. 단, 활성 및 비활성의 연결 데이터블록들은 동일한 메모리맵 파일 영역, 즉, 데이터 영역(20)을 공유한다.

제어 영역(30)은 어느 연결 리스트가 활성 데이터를 포함하고 있는지를 나타낸다. 제어 영역의 구성요소인 플립플롭 메커니즘은 데이터블록의 연결 리스트를 가리키는 활성 포인터(31) 및 비활성 포인터(32) 간의 토글링 작용을 함으로써 메모리맵 파일을 읽는 모든 응용 프로세스가 항상 최신 데이터에 액세스하도록 한다. 따라서 마스터 데이터베이스에서 온 데이터를 복제하는 동안에, 비활성 부분의 데이터블록을 먼저 삭제하여 새로 들어오는 데이터를 채우도록 한다. 신규 데이터의 삽입이 완료되면, 상기 플립플롭 메커니즘이 메모리 공유 파일의 데이터 영역 내의 활성 및 비활성 부분 간의 전환을 일으키도록 제어 영역이 편집된다. 그러나, 이러한 기존의 메커니즘은 두 가지 문제를 발생시킨다.

- 첫 번째 문제는, 메모리맵 파일의 실제 크기에 대해서, 저장해야 할 신규 데이터의 양에 대한 문제이다. 이미 위에서 언급한 바와 같이, 메모리맵 파일의 크기는 저장할 데이터의 증가 또는 감소에 따라 동적으로 변경될 수 없다. 따라서 저장할 데이터의 양이 사용가능 크기보다 더 커지면 메모리맵 파일을 현실적으로 업데이트할 수 없게 된다. 따라서, 해당 캐시 파일의 내용은 노후 정보가 된다. 따라서 이 문제를 해결하기 위해 수작업이 필요해진다. 메모리맵 파일의 크기는 복제를 재개하기 전에 증가시켜야 한다. 반대로, 메모리맵 파일의 크기가 과잉되면 많은 메모리 자원이 낭비된다. 또한, 저장할 데이터의 양이 감소하는 경우에, 기존 메커니즘은 메모리맵 파일의 크기를 줄이는 데에 이를 활용할 수 없다.

- 두 번째 문제는 복제시에 프로세스가 어떤 이유로 정상적으로 완료되지 못할 때에 발생한다. 활성 및 비활성 데이터블록은 동일한 데이터 영역을 공유하므로, 데이터 영역의 비활성 부분으로의 쓰기(write)에 의해서 메모리맵 파일의 활성 부분이 손상될 가능성도 있다. 복제 프로세스에서 데이터블록의 전체 리스트를 쓰는(write) 데 실패할 경우에는, 해당되는 연결 리스트가 실제로 손상된다. 이에, 활성 부분의 블록을 지정(address)하게 되는 등의 예기치 않은 결과가 예측되며, 이로써 데이터 영역의 활성 및 비활성 부분 간의 구별이 깨지게 된다.

위의 두 가지 문제는 이들 발생시에 촉발되는 불가피한 서비스 중단으로 인하여 영향받는 클라이언트 애플리케이션에게는 중대한 문제가 된다. 영향받는 클라이언트에 알릴 수 있도록 하기 위해 그리고 데이터 손상이 더 이상 확산되는 것을 방지하기 위해, 복제 프로세스의 표준 관행에는 데이터를 쓰기 전에 메모리맵 파일을 잠금(lock)처리하는 것이다. 복제가 정상적으로 종료되지 않는 경우에는 복제의 종료시에 잠금을 해제한다. 이 잠금 메커니즘은 데이터 손상이 더 이상 확산되는 것을 방지하고 클라이언트에게 손상된 파일을 볼 수 있는 가능성을 제공하기는 하지만, 자동으로 복귀되지는 않는다.

따라서, 기존의 복제 과정에서는 탄력성이 부족하며 수작업을 필요로 하는데, 이는 위에서 논의한 것과 같은 아래의 이유 때문이다.

- 메모리맵 파일의 크기는, 수동으로 설정해야 하며 해당 애플리케이션에 필요한 크기보다 과잉된 경우에는 많은 메모리 자원이 낭비되는 정적인 파라미터이다.

- 공유 데이터 영역에 있는 파일들 간의 플립플롭 메커니즘에 의해서는 연결 리스트의 손상이 일어나는 것을 막지 못한다. 그리고

- 잠금 메커니즘이 자동으로 복귀되지 않는다.

따라서 본 발명의 목적은, 캐시 파일을 마스터 데이터베이스로부터 미들웨어 처리 노드의 공유 메모리로 복제하는 기존 메커니즘의 상술한 단점과 한계의 적어도 일부를 해결하기 위한 것이다. 본 발명의 구체적인 목적은, 복제 연산이 자주 실패하거나 예상대로 완료되지 않는 경우라도, 절대적으로, 캐시 파일의 복제가 기존 캐시 파일에 대한 오류없는 프로세스가 되도록 하는 것이다.

본 발명의 다른 목적은, 데이터 버전을 용이하게 제어할 수 있는 신규의 캐시 구조를 제공하는 것이다.

본 발명의 그 밖의 목적, 특징, 장점은 첨부도면을 참조하여 설명한 이하의 상세한 설명을 당업자가 검토함에 의해 명확해질 것이다. 어떠한 추가적인 장점이라도 본 발명에 포함된다.

본 발명은 다수의 캐시 파일을 갖는 데이터 영역(각 캐시 파일은 일 버전의 동일한 데이터 세트를 저장하고 있음)과; 하나의 단일 캐시 파일의 데이터를 주소지정하는 적어도 하나의 키를 각각 저장하고 있는 다수의 버전 섹션을 갖는 적어도 하나의 버전 영역과, 하나의 버전 섹션을 포인팅하며 이들 버전 섹션과 같은 수의 옵셋을 포함하는 적어도 하나의 릴리스 영역을 포함하는 제어 영역;을 포함하는 캐시 메모리 구조에 관한 것이다.

따라서 중간 구조는 데이터 영역에서 분리되어 형성된다.

본 발명의 예시적 구현형태에 따른 한 측면에서, 제어 영역은 데이터 영역에서 분리된 파일인데, 이는 데이터 부분에 비해 제어 부분에 더 나은 보호를 제공하기 위함이다.

몇 가지 실시예에 따른 다른 측면에서, 3개의 옵셋과 3개의 버전 섹션이 제공되는데 기존의 플립플롭 메커니즘과는 다른 포인팅(pointing) 절차가 가능해진다. 3개 옵셋의 사용에 의해서 버전 간의 이동이 보다 안전해지고, 업데이트 단계에서의 충돌의 경우에도 응용 프로세스에 의해서 데이터의 가용성이 보존된다. 추가적으로, 3개 옵셋 중 하나는 교체된 버전 섹션으로의 액세스를 유지 -- 일시적이라도 -- 하는 데 사용할 수 있다. 따라서 이전의 현재 버전 섹션(previously current version section)에 대해서 동작을 시작한 응용 프로세스는 신규 버전 섹션이 도입되어 작동되었다 하더라도 계속해서 동작한다(즉, 현재 버전 섹션으로서 액세스할 수 있다). 신규 버전 섹션으로의 이동은 항상, 이 버전 섹션의 메모리를 재설정함으로써 시작된다. 키 위치 값으로의 버전 섹션을 통한 액세스는 원자적이지 않기 때문에(맵 키를 찾는 것과 같음), 기본적인 플립플롭 메커니즘을 사용하여 두 연속된 버전을 빠르게 성공적으로 이동시키게 되면 키 읽기와 충돌하게 될 수 있다. 3개의 옵셋의 사용에 의한 일시적인 액세스가 이에 대처할 수 있다.

본 발명은 또한 아래의 단계를 포함하는 업데이트 과정 중에 캐시 메모리에 저장된 데이터에 액세스하는 것을 제어하는 방법에 관한 것이다. 즉,

- 본 발명의 캐시 메모리 구조를 사용하여,

- 하나의 별도의 옵셋으로써 각 버전 섹션을 포인팅하고,

- 현재 버전 섹션으로서 정의된 하나의 버전 섹션을 포인팅하는 그리고 현재 데이터로서 정의된 데이터 집합의 버전을 주소지정하는 현재 옵셋으로 하나의 옵셋을 정의함.

본 발명은 복제 연산이 실패하거나 예상대로 완료되지 않는 경우라도, 절대적으로 캐시 파일의 복제가 오류없이 진행되고, 데이터 버전을 용이하게 제어할 수 있는 신규의 캐시 구조를 제공함으로써, 안정적인 서버/클라이언트 컴퓨팅 아키텍처를 구현하는 효과를 가진다.

이제 바람직한 구현형태를 설명하기 위하여, 도면을 참조해서 본 발명에 대해 상세히 설명한다.
도 1은 본 발명이 실시되는 종래의 3 계층 컴퓨팅 아키텍처를 나타낸다.
도 2는 종래 기술의 캐시 파일 구조를 나타낸다.
도 3은 3 계층 컴퓨팅 아키텍처의 중간 계층에서 버전 제어 파일을 이용하여 본 발명을 어떻게 실현하는지를 나타낸다.
도 4는 버전 제어 파일의 기본 구조를 나타낸다.
도 5a~5i는 공유 메모리에 신규 데이터 스냅샷을 원자적 방식으로 추가하는 방법의 절차를 나타낸다.
도 6은 업데이팅 프로세스를 최적화하고 동시 쓰기를 처리하기 위하여, 버전 제어 파일의 기본 구조에 대해 이루어진 제1 실시예를 나타낸다.
도 7a~7d는 버전 제어 파일의 개선된 구조에서의 신규 키의 추가에 대해서 설명한다.
도 8은 필요할 때 릴리스 영역의 메모리 크기가 증가되도록 버전 구조에 대해 이루어진 제2 실시예를 나타낸다.

이하의 상세한 설명에 사용된 몇 가지 용어에 대한 정의는 다음과 같다.

- 데이터 영역(data area)은, 프로세스가 액세스하여 데이터가 저장되고 쓰기 및 읽기 연산이 일어나는 캐시 메모리의 일부를 의미한다. 하나의 바람직한 실시예에서, 읽기 연산(read operation)은 응용 프로세스(applicative process)에 의해 이루어지고, 쓰기 연산(write operation)은 관리자의 과제로서 이루어진다. 관리자의 컴퓨터 장치에 의해 데이터가 업데이트/교체/생성될 때, 데이터는 응용 프로세스에 제공되고 응용 프로세스가 이를 읽을 수 있게 된다. 하나의 바람직한 실시예에서, 데이터는 데이터 집합들(sets of data)로 구성되는데, 각각이 객체(object)의 정의를 나타낸다. 예를 들자면, 항공사 전산 시스템의 규칙 또는 운임 정의 또는 비행 일정 데이터의 목록을 객체로서 사용할 수 있다. 객체는 또한 단일 데이터 필드의 내용(컨텐트)으로 구성될 수 있다. 데이터의 집합에 의해 정의되는 객체는, 일반적으로, 마스터 데이터베이스에서 관리자에 의해 이루어진 변경을 반영하도록 변경될 수 있는데, 이는 데이터 집합을 업데이트하거나 교체할 필요가 있다는 것을 의미한다. 또한 여기에는, 동일한 객체에 대해서 다수 버전(version)의 데이터 집합이 공존하도록 본 발명이 다수 버전의 객체를 처리할 수 있어야 한다는 의미도 포함된다. 객체들은 또한 패키지 단위로 그룹화 할 수 있다. 예를 들자면, 비행 스케줄을 처리하는 다양한 규칙 목록들을 비행 스케줄 패키지 단위로 그룹화 할 수 있다. 그러나 이 패키지도 여전히 하나의 객체, 즉, 데이터의 집합으로 볼 수 있다. 본 상세한 설명에서는 하나의 객체를 정의하는 데이터 집합의 일 버전 또는 객체 집합의 소정 버전들에 해당되는 용어인 '스냅샷(snapshot)'도 사용한다. 데이터집합의 각 스냅샷 또는 버전마다 하나의 캐시 파일이 전속하는 것이 유리하지만, 이에 한정되는 것은 아니다. 일반적으로, 데이터 영역의 데이터에는, 이들 데이터의 도움을 받는 적어도 하나의 응용 프로세스(여기서는 하나 이상의 컴퓨터 장치 중 적어도 하나의 프로세서에 의해 실행되는 임의의 컴퓨터 프로세스를 의미함)가 액세스(access)한다. 응용 프로세스에는, 여행업의 전역 분배 시스템(global distribution system)에 사용되는 운임 검색 엔진과 같은 검색 엔진의 읽기 프로세스가 포함될 수 있다. 기존의 하드웨어 수단을 본 발명의 캐시를 지원하도록 사용할 수 있다. 데이터 액세스 방식은 공유 메모리에 관한 기존 기술에 의존할 수 있으며, 데이터의 물리적 저장소와 이들 데이터의 응용 프로세스 뷰 사이의 통신을 가능하게 하는 메모리맵 파일(memory-mapped file) 개념에 의존할 수 있다.

- 제어 영역(control area)은 위에서 설명한 데이터 영역의 데이터에 프로세스가 액세스하는 것을 제어하는 데 사용되는 캐시의 일부를 의미한다. 제어 영역은 바람직하게는, 데이터 영역과 분리된 하나 또는 여러 개의 전용 캐시 파일 내에 포함된다. 이 파일을 이하에서는 제어 파일(control file) 또는 버전 제어 파일(version control file)이라고 부른다. 제어 영역은, 엔트리 포인트 영역(entry point area)이 사용되는 실시예에서 다른 제어 수단과 협동할 수 있음은 추후에 설명할 것이다. 그리고 다수의 제어 영역(유리하게는 별도의 파일에 각각 있는 제어 영역)을 사용할 수 있다.

- 영역(area)(제어 영역, 데이터 영역, 엔트리 포인트 영역 등에 사용되는 영역)은 넓은 의미로 상기 메모리의 연속된 세그먼트가 아닌 캐시 메모리의 일부분을 지칭한다.

- 키(key)는 저장된 데이터의 주소를 지정하는 작은 크기의 데이터를 나타낸다. 키 값은 해당되는 저장 데이터의 위치를 제공한다. 키가 반드시 동일한 크기의 데이터 집합을 주소지정(adress)하는 것은 아니다. 즉, 키는 시거 객체(sigger object)를 기술하는 데이터 집합 내의 특정 필드에 액세스하는 데 사용할 수 있다. 다른 키는 객체의 데이터 집합이 있는 영역 또는 객체들이 있는 영역에 액세스하는 데 사용할 수 있다. 또 다른 키는 객체의 이전 스냅샷에 액세스하는 데 사용할 수 있다. 한 세트의 키들을 사용하여 동일한 객체의 여러 스냅샷들에 액세스할 수 있다. 데이터 영역에서 각 데이터 집합은 키에 의해 고유하게 식별된다. 키의 크기는 작은 것이 바람직하지만, 어떠한 임의의 크기라도 가질 수 있다. 유일한 제약 조건은 각 데이터 집합이 고유의 고정된 키에 연계되어야 한다는 것이다.

버전 제어 영역의 목적은 데이터 집합에 액세스하기 위하여 각 키를 유형화하는 것으로서, 이는, 예를 들어 메모리 주소에 연계함으로써 이루어진다. 따라서 본 발명의 이해를 위해서, 키는 주소 또는 액세스 링크와 동등한 것으로 간주할 수 있다.

도면과 관련하여 본 발명의 바람직한 구현형태를 설명하기 전에, 본 발명의 몇 가지 옵션적 특징에 대해서 이하 소개한다. 다음의 특징들을 택일해서 또는 중첩해서 사용할 수 있다.

- 버전 섹션(version section)에는 키의 추가 또는 제거를 가능케 하는 구조(맵(map) 등)가 포함된다.

- 데이터의 스냅샷들을 도메인별로 그룹화 할 수 있다. 도메인 수준에서 동일한 제어 구조가 적용된다.

- 제어 영역은, 메인 버전 섹션(main version section)을 갖는 메인 릴리스 영역(main release area)을 포함하고 있다. 여기서 상기 각 메인 버전 섹션은 각 도메인별로 도메인 정의 데이터(domain definition data)를 포함하는데, 이 도메인 정의 데이터에는 전속된 릴리스 영역, 즉, 상기 도메인 릴리스 영역과의 액세스 링크(access link)가 포함된다.

- 메인 릴리스 영역은 메인 버전 섹션과 같은 수의 메인 옵셋(main offset)을 포함하며, 각 도메인 릴리스 영역마다 도메인 버전 섹션과 같은 수의 도메인 옵셋을 포함한다.

- 공유 메모리로 구성된다.

- 제어 영역은 또한 릴리스 영역(release area) 개념을 사용하여 관리할 수 있다. 이때 엔트리 포인트 제어 영역(entry point control area)은 다음을 포함하고 있다.

ㆍ 다수의 제어 영역,

ㆍ 각 엔트리 버전 섹션(entry version section)을 포함하는 엔트리 포인트 릴리스 영역(entry point release area) -- 각 엔트리 버전 섹션은 하나의 별도의 제어 영역으로의 액세스 링크를 정의함,

ㆍ 상기 엔트리 포인트 제어 영역은 엔트리 버전 섹션과 같은 수의 엔트리 옵셋(entry offset)을 포함하는데, 각 엔트리 옵셋은 하나의 엔트리 버전 섹션을 포인팅한다.

바람직한 구현형태에 따르면, 본 방법은 다음 단계 중 하나 이상을 포함할 수 있다.

- 신규 버전 섹션(현재 버전 섹션과는 다름)으로서 정의된 하나의 버전 섹션을 포인팅하는 신규 옵셋으로 하나의 옵셋을 정의하는 단계,

- 신규 버전 섹션을 소거(clear)하는 단계,

- 데이터 영역의 캐시 파일에, 적어도 하나의 데이터 집합의 신규 버전을 저장하는 단계,

- 신규 버전 섹션에 신규 버전 정보를 저장하는 단계,

- 현재 옵셋이 신규 버전 섹션을 포인팅하도록 하는 단계,

- 3개의 옵셋과 3개의 버전 섹션을 릴리스 영역에 제공하는 단계,

- 하나의 별도의 옵셋을 써서 각 버전 섹션을 포인팅하는 단계,

- 현재 버전 섹션으로서 정의된 하나의 버전 섹션을 포인팅하고 현재 데이터로서 정의된 데이터 집합의 버전을 주소지정하는(addressing) 현재 옵셋으로 제1옵셋을 정의하는 단계,

- 신규 버전 섹션(현재 버전 섹션과는 다름)으로서 정의된 하나의 버전 섹션을 포인팅하는 신규 옵셋으로 제2옵셋을 정의하는 단계,

- 과거 버전 섹션으로서 정의된 하나의 버전 섹션을 포인트하는 과거 옵셋으로 제3 옵셋을 정의하는 단계,

- 신규 버전 섹션을 소거하는 단계,

- 과거 옵셋이 현재 버전 섹션을 포인팅하도록 하는 단계,

- 현재 옵셋이 신규 버전 섹션을 포인팅하도록 하는 단계,

- 신규 옵셋이 과거 버전 섹션을 포인팅하도록 하는 단계,

- 과거 옵셋이 현재 버전 섹션을 포인팅하도록 한 후에, 과거 옵셋이 포인팅하는 버전 섹션에 의해 주소지정된 캐시 파일의 데이터에 응용 프로세스가 액세스하도록 하는 단계,

- 상기 액세스는 유한한 시간에 이루어지도록 하는 단계,

- 캐시 메모리 구조를 사용하는 단계,

- 현재 엔트리 섹션으로서 정의된 하나의 엔트리 섹션을 포인팅하는 현재 엔트리 옵셋으로 하나의 엔트리 옵셋을 정의하는 단계,

- 현재 엔트리 옵셋에 의해서 주소지정된 제어 영역에 응용 프로세스가 액세스하도록 하는 단계.

본 발명은 또한, 본 발명의 방법을 수행하기에 적합한 명령어를 포함하는 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품에 관한 것이다. 이 프로그램은, 컴퓨터 판독가능 메모리와 같은 일시적 매체에 저장될 수 있다.

도 3은 배경기술 항목에서 설명한 3 계층 아키텍처 환경에서, 버전 제어 파일을 이용하여 본 발명을 어떻게 실현하는지를 나타낸다.

목적을 달성하기 위하여 본 발명은 각 공유 메모리(230) 내에, 중간 캐시 파일(220)을 사용한다. '제어 파일'이라고도 하는 이 파일은 공유 메모리에 저장된 다양한 캐시 파일(250)의 층으로 응용 프로세스(240)가 액세스하는 모든 것을 관리하는 데 사용된다. 도면에서와 같이 모든 응용 프로세스(240)는 버전 제어 파일(220)을 통해 캐시 파일(250)에 액세스하고 오류없는 복제 메커니즘을 실현한다.

버전 제어 파일(220)로써 구현되는 제어 영역은, 키는 버전있는 데이터(versioned data)이고 그 값은 데이터의 특정 버전의 위치인 맵(map) 구조로 볼 수 있다. 캐시 버전 제어는 다음과 같은 방식으로 액세스가능하다.

쓰기: 신규 키가 그 최초 버전과 함께 추가된다.

쓰기: 기존 키의 값이 업데이트된다.

읽기: 키의 현재 값이 호출된다.

쓰기에 대한 읽기의 비율이 높은 본 발명의 바람직한 상황에서, 쓰기 액세스는 모든 읽기 액세스에 영향을 주지 않아야 한다. 다른 말로, 어떠한 쓰기 연산이 실행되고 있더라도 모든 키 값은 읽기에 액세스 가능한 상태에 있어야 한다. 다음 도면에서 설명할 것이지만, 본 발명은 따라서 다음과 같은 문제를 해결하게 된다.

- 캐시 메모리에 키와 값을 쓰는 것은 원자적 연산(atomic operation)일 수 없다. 그럼에도 불구하고, 읽기 연산은 쓰기 연산 중에 보류되지 않는다. 대신에, 캐시 파일에의 쓰기 연산이 인터럽트될 수 있다. 따라서 완료되지 않은 쓰기 연산은 읽기 완료시에 재개되도록 할 수 있다.

- 일단 캐시 버전 제어가 시작되면, 여기에는 유한한 수량의 키가 포함될 수 있다. 신규 키를 추가할 필요가 있을 때마다, 본 발명은 이 한정된 수량에 도달할 때에 공유 메모리에 신규 영역을 할당하게 된다.

- 동시 쓰기는, 쓰기 연산에 대해 독점적인 액세스 권한을 부여함으로써 처리된다.

도 4는 제어 파일(220)에 해당하는 제어 영역의 기본 구조를 나타낸다.

버전 제어를 조직화하는 데 있어서, 쓰기에 대한 읽기 전용 연산의 우선순위를 유지하면서(즉, 읽기 서비스를 인터럽트 하지 않고), 1군의 다수 쓰기 연산들의 원자성(atomicity)을 공유 메모리에서 얻을 수 있다. 이는 이하에서 설명하는 것과 같다.

- 공유 메모리의 데이터 파티션(데이터 영역(410)으로 지칭)은 임의의 주어진 시간에 수신된 데이터의 모든 스냅샷을 저장하기 위해 사용된다.

- 각 데이터 스냅샷은 공유 메모리의 자체 전용 영역(420)에 저장된다. 이러한 전용 영역(420)은 도 3에 나타낸 하나의 캐시 파일(250)인 것이 바람직하다.

- 공유 메모리의 릴리스 영역(430)이라고 지칭한 영역은 수신된 데이터 스냅샷의 버전을 제어하기 위한 것이다. 즉, 어느 데이터 스냅샷이 현재 데이터 스냅샷인지를 나타낸다.

- 릴리스 영역은 하나 또는 여러 데이터 집합 중에서 어느 것이 현재 데이터 스냅샷인지를 나타낸다.

- 신규 데이터 스냅샷의 추가는 원자적으로 수행된다. 본 발명에서, 공유 메모리에서 옵셋, 즉, 정수값을 업데이트하는 것은 원자적 연산인 것으로 가정한다.

공유 메모리의 데이터 영역(420)이 미리 정해진 크기일 필요는 없다. 그 크기는 구성시에 계산되는데, 공유 메모리를 사용하는 소프트웨어 애플리케이션의 요구 사항을 충족하도록 계산된다. 반대로, 공유 메모리의 릴리스 영역의 크기는 고정되어 있는데, 이는 다음과 같이 네 가지 하위 영역으로 나뉜다.

- 하나의 영역(440)에, 버전 영역(450)에 포함되는 세 버전 섹션을 주소지정하기 위한 옵셋(442)이 포함된다. 세 버전 섹션들은 다음과 같이 구성된다.

- 현재 버전 섹션(454). 여기에는 각 데이터 집합의 현재 스냅샷의 주소(다르게 말하자면, 키)가 포함된다.

- 신규 버전 섹션(456). 여기에는 데이터 집합의 신규 또는 최신 데이터 스냅샷의 주소가 포함된다.

- 과거 버전 섹션(452)에는 이전에 현재 버전이라고 식별된 각 데이터 스냅샷의 주소가 포함된다.

각 버전 섹션의 크기는 고정되어 있고 단지 스냅샷의 최대 유한 수를 처리할 수 있을 뿐이다. 이는, 스냅샷을 주소지정하는 유한한 수의 키가 처리될 수 있다는 것을 의미한다.

도 5a~5i는 공유 메모리에 신규 데이터 스냅샷을 원자적 방식으로 추가하는 방법의 단계를 나타낸다.

도 5a에 도시된 바와 같이, 사전 단계(이하에서 논의함)에서 영역(440) 내의 옵셋의 일관성을 확인(체크)하고 보정을 행한(필요시에) 후에, 그 다음의 첫 번째 단계, 즉 단계 2에서는 신규 버전 섹션(456)을 소거한다. 즉 모든 비트를 영으로 설정한다(457). 이에, 신규 버전 섹션(456)이 초기화된다(458). 즉, 다음 단계 3에서, <키, 위치 값> 쌍을 포함하는 내부 구조가 생성된다. 이 단계의 결과는 도 5b에 나타내었다.

도 5c에 나타낸 다음 단계 4에서는 데이터 영역(410)의 새로운 영역(420)에 신규 데이터 스냅샷을 저장한다. 이 단계는 완전히 새로운 데이터 스냅샷을 저장함으로써, 또는 현재 데이터 스냅샷을 먼저 검색한 다음에 이를 업데이트함으로써 수행된다. 그러나 두 경우 모두에서 스냅샷은 새로운 데이터 영역(420)에 저장되는 것이 유리하다.

다음, 단계 5에서 현재 버전 섹션(454)의 내용이 신규 버전 섹션(456)에 복사되어, 키 링크 455가 현재 버전 섹션(454)의 데이터 스냅샷과 동일한 데이터 스냅샷을 주소지정하도록 한다. 이를 도 5d에 나타내었다. 다음 단계 6에서(도 5e 참조), 신규 버전 섹션(456)을 변경하여 신규 데이터 스냅샷을 포함하는 데이터 영역(420)을 대신 주소지정하도록 한다(링크 459).

그 후, 단계 7에서, 영역 440의 옵셋(442)들을 다음과 같이 변경한다.

- 단계 71에서, 과거 옵셋이 이제는 현재 섹션(454)을 주소지정하고,

- 단계 72에서, 현재 옵셋이 이제는 신규 섹션(456)을 주소지정하고,

- 단계 73에서, 신규 옵셋이 이제는 과거 섹션(452)을 주소지정함.

영역 440의 옵셋(442)들의 일관성을 체크하는, 위에서 언급한 사전 단계 또는 단계 1의 목적은 영역 440에서의 쓰기 연산 중에 발생할 수 있는 오류를 처리하기 위한 것이다.

도 5g에 나타낸 것과 같이, 오류 후에는 두 옵셋이 동일한 버전 섹션을 주소지정할 수 있다(451 참조). 이 경우에 영역 440의 신규 또는 과거 옵셋을 간단하게 보정하여 이를 해결할 수 있다. 보정은 현재 섹션을 대상으로 하는 신규 및 과거 옵셋 중 하나에 단순히 적용된다.

단계 2~6을 실행하는 중에 업데이트 프로세스가 실패할 경우, 신규 데이터 스냅샷의 추가는 바로 취소된다. 변경된 버전 섹션만이 신규 섹션(456)이기 때문이다. 이 섹션에 대해서는 읽기 연산이 액세스되지 않는다. 읽기 연산은 현재 버전 섹션만을 사용한다. 따라서, 공유 메모리를 업데이트하는 시도가 실패해도 부작용은 없는데, 그 이유는 위에서 설명한 것과 같이 다음 번 쓰기를 할 때에 신규 버전 섹션이 삭제되고 처음부터 시작될 것이기 때문이다. 또한 신규 데이터 영역(420)은, 아직 릴리스 영역(430)에 의해 참조되지 않았기 때문에 다시 사용될 것이다.

단계 71, 72를 실행하는 동안에 프로세스가 실패하는 경우, 스냅샷 추가도 또한 취소되는데, 그 이유는 읽기 연산은 여전히 현재 버전 섹션을 대상으로 하고 있기 때문이다. 이러한 실패의 경우에도 부작용이 없는데, 위에서 설명한 것과 같이, 새로운 데이터 스냅샷을 추가하고자 할 다음 번 시도에 의해서 신규 버전 섹션이 삭제되고 처음부터 시작될 것이기 때문이다. 현재 버전 섹션을 주소지정하는 과거 옵셋을 갖는 것은 문제가 되지 않는다. 일관성을 체크하고 옵셋을 보정하는 사전 단계에서 이를 해결할 것이다. 데이터 영역(410)에 신규 데이터 스냅샷(420)을 추가하는 시도를 하는 중에 오류에 의해 영역 440이 손상된 후의 릴리스 영역(430)의 상태를 도 5g에 예시적으로 나타내었다. 옵셋(442)이 회복된 후의 상황은 도 5e에 나타낸 것과 같다.

그러나 단계 72와 73 사이에서 프로세스가 실패하면 스냅샷 추가는 취소되지 않고 성공적으로 완료된 것으로 간주된다. 실제로, 읽기 연산은 지금 막 새로 구성된 버전 섹션(456)인 현재 버전 섹션을 대상으로 할 수 있는 것이 현실적이다. 그러나 업데이트 연산이 정상적으로 완료되지 않았기 때문에 영역 440의 신규 옵셋은 여전히 현재 버전 섹션(456)을 주소지정하고 있다(453 참조). 새로 구성된 버전 섹션을 다음 번 쓰기 연산의 단계 1이 삭제하지 못하도록 하기 위해, 이 섹션도 역시 현재 버전 섹션이라는 것에 근거하여, 옵셋의 일관성을 확인해야 하고 단계 1에서 보정을 행해야 한다. 신규 옵셋 및 현재 옵셋이 동일한 버전 섹션(456)을 주소지정(453)하기 때문에 옵셋 불일치는 쉽게 감지된다. 이는 오류가 단계 72 직후에 발생했음을 나타내는 것이다. 완전히 오류를 복구하려면 신규 옵셋을 이전의 과거 버전 섹션을 주소지정하도록 설정하면 된다. 즉, 나머지 버전 섹션(이 예에서는, 452)은 어떠한 옵셋에 의해서도 주소지정되지 않도록 한다.

도 5h에 이러한 예를 나타낸다. 이 예에서, 신규 스냅샷(422)을 추가하는 과정은 단계 72 이후에 실패하였다. 단계 1에서 옵셋의 복구가 수행된 후의 릴리스 영역의 상태를 도 5i에 나타내었다. 신규 제어 섹션이 올바른 버전 섹션(이 예에서는 452)을 주소지정하도록 보정되었다(455 참조). 여기서, 프로세스가 단계 73 이후에 실패하더라도 스냅샷의 원자적 추가가 이미 완료되었기 때문에 나쁜 결과는 나오지 않음을 주목해야 한다.

앞에서 도 4와 5에서 설명한 버전 제어 파일 및 그 동작 양식은 아래와 같은 문제에 대처하기 위해 변형할 수 있다. 즉,

- 전역 잠금 메커니즘이 사용되기 때문에 동시 쓰기가 지원되지 않음.

- 릴리스 영역의 크기가 고정되어 있음.

다음의 도면에서는 이들 잔여 문제를 해결하기 위한, 기본적 버전 제어 파일의 개선 실시예에 대해서 설명하고 있다.

도 6은 업데이팅 프로세스를 최적화하고 동시 쓰기를 처리하기에 최적화된 제1 개선 실시예를 나타낸다.

본 발명은, 특정 키 값의 업데이트 수에 비해 신규 키 삽입의 수가 일반적으로 적은 환경에서 작용한다. 이러한 상황에서, 앞의 도 4와 도 5에서 설명한 버전 제어의 기본 구조의 동작에는 한 가지 제한이 있다. 앞에서 단계 4에서 설명했듯이, 릴리스 영역(430)의 섹션(452, 454, 456)에서 키 값을 변경해야만 할 때마다 전체의 버전 맵(즉, 모든 키 데이터)을 적어도 한 번은 우선적으로 복사해야 한다. 이러한 단점을 극복하기 위해, 본 발명에서는 메인 릴리스 영역(436) 및 다수의 릴리스 영역(432, 434)을 생성하는 데 있어서 앞에서 설명한 캐시 제어 구조를 개선한다. 즉, 다수의 릴리스 영역(432, 434)은 삽입된 키 값을 현재 처리하는 반면에 메인 릴리스 영역은 본 상황에서 도메인 릴리스 영역이라 명명되는 이들 릴리스 영역을 억세스하기 위한 도메인 키 정의를 유지한다.

이 구현형태에 따르면, 데이터 영역의 데이터(또는 적어도 데이터들 중 일부)는 여러 도메인에 분산된다. 도메인들은 일반적으로 크기가 동일하지 않으며 각각 1군의 데이터 집합에 대응된다. 그 특성은 몇 가지 공통점을 갖는다. 예를 들면, 어느 한 항공사에 대한 규칙에 어느 한 도메인을 할당할 수 있고, 다른 항공사의 규칙에 다른 도메인을 할당할 수 있다.

도 6은 릴리스 영역의 기본 구조를 개선하는 방식을 예로서 설명하고 있다. 이 예에서는, 앞에서 설명한 릴리스 영역(430)은, 두 개의 도메인 키, 즉, 1A-POS와 AF-MKT(각자 자신의 버전을 가짐)를 갖고 있는, 메인 릴리스 영역(436)과 함께 사용되는 릴리스 영역(432, 434)으로 대체된다. 이 개선된 구조에서, 메인 릴리스 영역(436)은 단지, 각각 자신의 릴리스 영역(이 예에서는 434 및 432)에 연계된 저장된 키들을 참조하는 데 사용된다. 1A-POS 값 및 AF-MKT 값 릴리스 영역으로의 모든 링크를 참조번호 610으로 표시한다. 이 개선된 구조에 의하여 하나의 도메인 키를 추가하고(이는 특히, 신규 객체가 캐시에 추가될 때에 발생할 수 있음) 및 키 값을 변경하는 프로세스를 이하에서 설명한다.

도 7a~7d는 도 6의 개선된 구조에서 새 도메인 키를 추가하는 것을 설명한다. 이것은 메인 릴리스 영역(436)과 릴리스 영역(432)에 각각 어떻게 신규 도메인 키 정의 데이터 및 값이 추가되는지를 나타내고 있다.

제어 파일(220) 생성시에, 메인 릴리스 영역(436)과 특정 개수의 값 릴리스 영역(예컨대, 432 및 434)이 미리 구성된다. 따라서 가장 효율적인 메모리 관리 방법은 메인 릴리스 영역(436)의 최대 용량에 정합되는 수의 릴리스 영역을 할당하는 것이다.

도 7a는 프로세스의 시작 단계(즉, 단계 10)를 나타낸다. 여기서 메인 릴리스 영역(436)은 하나의 도메인 키, 즉, 1A-POS 만을 보유하고 있다. 이 개선된 구조에서 메인 릴리스 영역(436)은, 객체 1A-POS의 여러 스냅샷 버전의 위치/키, 즉, 1A-POS 버전 2, 3, 4를 보유하는 종속 도메인 릴리스 영역인 "1A-POS 릴리스 영역"(434)을 주소지정하는 메인 제어 섹션 A, B, C를 포함하고 있다. 상기 1A-POS 버전 2, 3, 4는 각각, 종속 도메인 릴리스 영역의 과거, 현재, 신규 도메인 버전 영역 내의 버전을 나타낸다. 지정 링크(612)는 메인 릴리스 영역(436)과 이에 종속된 도메인 릴리스 영역(434) 사이에 생성된다. 이 도메인 릴리스 영역(434)은 본 발명의 제1구현형태에서 설명한 옵셋을 포함한다. 이는 또한 메인 릴리스 영역(436)의 경우에도 그러하다. 도 6과 7은 메인 릴리스 영역(436)에도 옵셋(여기서는 메인 옵셋이라고 부름)이 포함됨을 나타내고 있다. 이 예에서, 메인 릴리스 영역(436)과 릴리스 영역(432, 434)의 구조는 비슷하지만, 옵셋 및 메인 옵셋의 개수는 다를 수 있다. 단, 여기 예에서는 각각에 대해 3개의 옵셋을 사용하고 있다.

다음 단계 11이 도 7b에 도시되어 있는데, 여기서는 신규 도메인 키(즉, AF-MKT)가 메인 릴리스 영역(436)에 추가 되고 해당 값의 릴리스 영역(432)이 지정된다. 이를 위해, 이 신규 도메인 키의 정의 데이터가, 이 종속 도메인 릴리스 영역(432)을 주소지정하는 지정 링크(614)를 제공하기 위하여 메인 릴리스 영역(436)에서 정의된다.

그 다음, 도 7c의 단계 12에서 도 5에서 설명한 프로세스가 적용된다. 옵셋은, 종속 도메인 릴리스 영역(432) 내에 새로 삽입된 도메인 키 AF- MKT V1이 현재 키가 되도록 변경된다(620).

마찬가지로, 메인 릴리스 영역(436)의 메인 옵셋은, 키의 메인 버전 섹션 C를 지정하도록 변경되어 현재 키가 되도록 한다(경로 630). 이는 단계 13에서 수행되며 그 결과는 도 7d에 나타내었다. 이 단계가 완료됨으로써, 쓰기 연산, 즉, 신규 도메인 키의 추가가 성공적으로 완료된다.

객체의 업데이트는 도 5에서 설명한 것과 같이 수행된다. 따라서 특정 값만을 업데이트하면 되는데, 이때는 도메인 릴리스 영역(432, 434)의 수준에서 해당 값들만을 조작하면 된다. 따라서 이 과정 중에 메인 릴리스 영역(436)의 전체 섹션의 복사가 방지될 수 있다.

개선된 버전 제어 구조에서는, 업데이트되는 영역이 공유 메모리 내에서 완전하게 분리되기 때문에 동시 쓰기가 가능해진다. 이에, 다음과 같은 작업을 동시에 수행할 수 있다.

- 메인 릴리스 영역(436)에 하나의 도메인 키를 추가.

- 다른 도메인 릴리스 영역의 값/객체를 업데이트.

따라서, 동시 쓰기 기능을 실시함에 있어서, 하나의 뮤텍스(mutex)(즉, 프로세스에서 공통된 자원(리소스)의 동시 사용을 방지하기 위해 고안된 코드)를 생성하여, 값마다, 그리고 메인 릴리스 영역에 대해 하나의, 쓰기 액세스 권한을 부여한다. 위에서 설명한 프로세스는, 쓰기 연산의 시작 부분에서 해당 뮤텍스(들)을 입수함으로써 재진입성(re-entrant)으로 된다.

도 8은 릴리스 영역의 메모리 크기를 증가시키는 버전 구조에 대한 제2의 개선 실시예로서, 앞에서 언급한 고정된 크기에 있어서의 문제를 해결하기 위한 실시예를 나타낸다.

할당되는 공간이 충분하여 신규 데이터를 추가하는 것이 간단한 경우에, 신규 데이터 집합과 그 제어 수단을 할당해야만 할 때에는 일이 더 복잡해진다. 본 발명은 간접성 수준(level of indirecrtion)을 추가함에 의하여 이 문제를 해결한다. 이를 위해, 엔트리 포인트 영역(710)이 사용되는데, 이는 캐시의 메모리 세그먼트가 될 수 있다. 엔트리 포인트 영역(710)의 역할은 따라서, 여러 제어 영역을 참조하는 것인데, 각 제어 영역은 제어 데이터를 보관하는 제어 파일(220)로 이루어지는 것이 유리하다. 엔트리 포인트 영역(710)은, 엔트리 섹션(715, 716, 717)을 자체적으로 포함하는 엔트리 포인트 릴리스 영역이 포함된 다른 캐시 파일인 것이 바람직하다. 각 엔트리 섹션에는, 하나의 버전 제어 영역 구조(이전 도면에서 설명하였음. 본 예에서는 720 및 730임)를 실제로 갖고 있는 하나의 제어 파일의 위치와 최대 용량(712)이 포함된다. 엔트리 포인트 영역(710)은 릴리스 영역과 전체적으로 동일한 구조를 갖는 것이 바람직하며, 또한 옵셋(여기서는 엔트리 옵셋)을 포함하는 것이 바람직하다.

키를 추가할 때, 쓰기 프로세스는 다음의 단계들을 수행한다.

1. 현재 제어 영역에 충분한 메모리 공간이 남아있는지 여부를 확인한다. 만일 충분한 공간이 남아 있으면 앞에서 설명한 것과 같이 쓰기가 이루어진다. 만약 남은 공간이 충분하지 않다면,

2. 크기가 증가된 신규 제어 영역을 생성한다. 예를 들어, 도 8에서 730과 같은 파일이 생성된다.

3. 현재 제어 영역으로부터의 데이터를 복사하여 신규 데이터를 만든다. 선택사항으로서, 과거 값을 검색할 필요가 있는 경우에는 캐시 값의 전체 내용을 복사하고, 그렇지 않으면 현재 값만을 복사한다.

4. 키를 신규 제어 영역(730)에 추가한다.

5. 현재 엔트리 옵셋(719)을, 생성된 제어 영역(730)을 포인팅하는 엔트리 섹션(717)으로 전환한다.

6. 리소스를 절약하기 위해, 중요도가 떨어져 더 이상 사용되지 않고 사라질(deprecated) 버전의 데이터를 삭제한다.

엔트리 포인트 영역(710)은 도 4와 5에 설명된 구조를 사용하여서 읽기 액세스를 방해하지 않으면서 현재 제어 영역이 전환될 수 있도록 한다.

엔트리 포인트는 고정된 크기의 구조를 포함하기만 하면 되기 때문에, 신규 할당을 필요로 하지 않으며 고정된 엔트리 포인트으로서의 역할을 할 수 있다.

신규 제어 영역 용량을 계산하는 정책을 자유롭게 적용할 수 있으며, 이 절차의 적용 횟수 및 전체 메모리 공간 간에는 절충이 있어야 한다.

읽기 액세스는 먼저 엔트리 포인트 영역을 읽어서 현재 제어 영역을 검색한다. 현재 제어 영역은, 메인 릴리스 영역의 현재 메인 옵셋이 현재 메인 버전 섹션을 주소지정하는 메인 릴리스 영역에 도달된다. 현재 메인 버전 섹션은, 올바른 도메인 릴리스 영역에 도달하도록 키 링크를 제공한다. 이 단계에서, 도메인 릴리스 영역의 현재 옵셋은 도메인 버전 섹션을 포인팅하여, 데이터 영역(420)이 액세스되도록 주소지정한다.

지금까지 본 발명의 예시적 구현형태를 첨부 도면을 참조하여 상세하게 설명하였지만, 본 발명이 상기 구체적인 구현형태에 한정되는 것이 아니며, 본 발명의 범위와 사상을 벗어나지 않는 범위에서 당업자에 의해 그 변경 및 수정이 이루어질 수 있음을 이해해야 한다.

Claims (17)

1. 장치에 있어서,
   메모리; 및
   상기 메모리 내에 저장된 캐시 메모리 구조
   를 포함하고, 상기 캐시 메모리 구조는,
   복수의 캐시 파일들을 갖는 데이터 영역으로서, 각각의 캐시 파일은 일 버전(version)의 데이터 집합(set of data)을 저장하도록 구성된 것인, 상기 데이터 영역; 및
   상기 복수의 캐시 파일들에 대한 액세스를 제어하도록 구성되고, 적어도 하나의 릴리스(release) 영역을 포함하는 제어 영역
   을 포함하고, 상기 적어도 하나의 릴리스 영역은,
   적어도 하나의 캐시 파일의 데이터를 주소지정(address)하는 적어도 하나의 키를 저장하도록 각각 구성된 제1 버전 섹션, 제2 버전 섹션, 및 제3 버전 섹션을 포함한 적어도 하나의 버전 영역; 및
   버전 옵셋(offset) 영역을 포함하고, 상기 버전 옵셋 영역은,
   상기 제1 버전 섹션, 상기 제2 버전 섹션, 및 상기 제3 버전 섹션 중 하나를 포인팅(point)하여 상기 포인팅된 버전 섹션을 신규 버전 섹션으로서 식별하도록 구성된 신규 옵셋,
   상기 제1 버전 섹션, 상기 제2 버전 섹션, 및 상기 제3 버전 섹션 중 하나를 포인팅하여 상기 포인팅된 버전 섹션을 현재 버전 섹션으로서 식별하도록 구성된 현재 옵셋, 및
   상기 제1 버전 섹션, 상기 제2 버전 섹션, 및 상기 제3 버전 섹션 중 하나를 포인팅하여 상기 포인팅된 버전 섹션을 과거 버전 섹션으로서 식별하도록 구성된 과거 옵셋을 포함한 것인 장치.
2. 제1항에 있어서, 상기 제어 영역은 상기 데이터 영역으로부터 분리된 적어도 하나의 파일을 포함한 것인 장치.
3. 제1항에 있어서, 각각의 버전 섹션은 하나의 단일 키에 할당된(assigned) 일 버전의 데이터 집합을 저장하는 하나의 캐시 파일에 액세스하기 위해 상기 하나의 단일 키와 연관된 값들을 저장하고, 복수의 데이터 집합들은 복수의 도메인들에 분산되어 있고, 상기 적어도 하나의 릴리스 영역은 적어도 하나의 도메인 릴리스 영역이고, 상기 제어 영역은,
   각각의 도메인 릴리스 영역에 대응하는 액세스 링크를 각각 저장하는 메인 버전 섹션들을 포함한 메인 릴리스 영역; 및
   제1 메인 버전 섹션을 포인팅하여 상기 제1 메인 버전 섹션을 신규 메인 버전 섹션으로서 식별하도록 구성된 신규 메인 옵셋, 제2 메인 버전 섹션을 포인팅하여 상기 제2 메인 버전 섹션을 현재 메인 버전 섹션으로서 식별하도록 구성된 현재 메인 옵셋, 및 제3 메인 버전 섹션을 포인팅하여 상기 제3 메인 버전 섹션을 과거 메인 버전 섹션으로서 식별하도록 구성된 과거 메인 옵셋을 포함한 도메인 옵셋 영역을 더 포함한 것인 장치.
4. 제3항에 있어서, 상기 복수의 데이터 집합들의 데이터 집합 각각은 특정 항공사에 대응하는 특정 도메인에 분산되어 있으며, 각각의 데이터 집합은 상기 특정 항공사의 영업 규칙(business rule)들에 대응한 것인 장치.
5. 제1항에 있어서, 상기 캐시 메모리 구조는 공유 메모리(shared memory)로 구성된 것인 장치.
6. 제1항에 있어서,
   복수의 제어 영역들; 및
   엔트리 섹션들을 포함한 엔트리 포인트 영역
   을 더 포함하며, 각각의 엔트리 섹션은 하나의 개별적인 제어 영역에 대한 액세스 링크를 저장하도록 구성된 것인 장치.
7. 제6항에 있어서, 상기 엔트리 포인트 영역은 엔트리 섹션들과 같은 수의 엔트리 옵셋들(as many entry offsets as entry sections)을 포함하며, 각각의 엔트리 옵셋은 하나의 엔트리 섹션을 포인팅하는 것인 장치.
8. 제1항에 있어서, 각각의 캐시 파일 내에 저장된 상기 데이터 집합은 적어도 하나의 항공사에 대한 비행 스케줄 패키지에 대응하며, 각각의 비행 스케줄 패키지는 요금 정의들 및 비행 스케줄 데이터를 포함한 것인 장치.
9. 캐시 메모리 및 프로세서를 포함하는 데이터 프로세싱 시스템의 상기 프로세서에 의해, 업데이트 스테이지들 동안 상기 캐시 메모리 내에 저장된 데이터에 대한 액세스를 제어하기 위한 방법에 있어서,
   캐시 메모리 구조를 이용하는 단계로서, 상기 캐시 메모리 구조는,
   복수의 캐시 파일들을 갖는 데이터 영역으로서, 각각의 캐시 파일은 상이한 버전의 데이터 집합을 저장하도록 구성된 것인, 상기 데이터 영역; 및
   상기 복수의 캐시 파일들에 대한 액세스를 제어하도록 구성되고, 적어도 하나의 릴리스 영역을 포함하는 제어 영역
   을 포함하고, 상기 적어도 하나의 릴리스 영역은,
   적어도 하나의 캐시 파일의 데이터를 주소지정(address)하는 적어도 하나의 키를 저장하도록 각각 구성된 제1 버전 섹션, 제2 버전 섹션, 및 제3 버전 섹션을 포함한 적어도 하나의 버전 영역; 및
   버전 옵셋(offset) 영역을 포함하고, 상기 버전 옵셋 영역은,
   상기 제1 버전 섹션, 상기 제2 버전 섹션, 및 상기 제3 버전 섹션 중 하나를 포인팅(point)하여 상기 포인팅된 버전 섹션을 신규 버전 섹션으로서 식별하도록 구성된 신규 옵셋,
   상기 제1 버전 섹션, 상기 제2 버전 섹션, 및 상기 제3 버전 섹션 중 하나를 포인팅하여 상기 포인팅된 버전 섹션을 현재 버전 섹션으로서 식별하도록 구성된 현재 옵셋, 및
   상기 제1 버전 섹션, 상기 제2 버전 섹션, 및 상기 제3 버전 섹션 중 하나를 포인팅하여 상기 포인팅된 버전 섹션을 과거 버전 섹션으로서 식별하도록 구성된 과거 옵셋
   을 포함한 것인, 상기 캐시 메모리 구조를 이용하는 단계, 및
   상기 현재 옵셋에 의해 포인팅된 버전 섹션에 의해 주소지정된 캐시 파일의 데이터에 대한 응용 프로세스에 의한 액세스를 인에이블하는 단계
   를 포함하는 데이터에 대한 액세스를 제어하기 위한 방법.
10. 제9항에 있어서,
    상기 신규 버전 섹션을 소거(clear)하는 단계;
    상기 신규 버전 섹션의 키에 의해 주소지정된 상기 데이터 영역의 캐시 파일 내에 신규 버전의 적어도 하나의 데이터 집합을 저장하는 단계;
    상기 신규 버전 섹션 내에 신규 데이터 버전 정의 정보를 저장하는 단계; 및
    상기 신규 버전 섹션을 포인팅하도록 상기 현재 옵셋을 수정하는 단계
    를 더 포함하는 데이터에 대한 액세스를 제어하기 위한 방법.
11. 제10항에 있어서,
    상기 현재 버전 섹션을 포인팅하도록 상기 과거 옵셋을 수정하는 단계; 및
    상기 과거 버전 섹션을 포인팅하도록 상기 신규 옵셋을 수정하는 단계
    를 더 포함하는 데이터에 대한 액세스를 제어하기 위한 방법.
12. 제11항에 있어서,
    상기 현재 버전 섹션을 포인팅하도록 상기 과거 옵셋을 수정한 후, 상기 과거 옵셋에 의해 포인팅된 버전 섹션에 의해 주소지정된 캐시 파일의 데이터에 대한 응용 프로세스에 의한 액세스를 인에이블하는 단계
    를 더 포함하는 데이터에 대한 액세스를 제어하기 위한 방법.
13. 제12항에 있어서, 상기 액세스를 인에이블하는 단계는 유한한 시간에 이루어지는 것인 데이터에 대한 액세스를 제어하기 위한 방법.
14. 제9항에 있어서,
    현재 엔트리 섹션으로서 정의된 하나의 엔트리 섹션을 포인팅하는 엔트리 옵셋을 현재 옵셋으로서 정의하는 단계; 및
    현재 엔트리 옵셋에 의해 주소지정된 상기 제어 영역에 대한 응용 프로세스에 의한 액세스를 인에이블하는 단계
    를 더 포함하는 데이터에 대한 액세스를 제어하기 위한 방법.
15. 제9항의 방법을 실행하기 위한 명령어들을 포함한 컴퓨터 프로그램이 저장되어 있는 컴퓨터로 판독가능한 비일시적(non-transitory) 기록 매체.
16. 캐시 메모리 및 프로세서를 포함하는 데이터 프로세싱 시스템의 상기 프로세서에 의해, 복수의 캐시 파일들을 갖는 데이터 영역과 상기 복수의 캐시 파일들에 대한 액세스를 제어하도록 구성된 제어 영역을 포함한 캐시 메모리 구조를 포함하는 상기 캐시 메모리 내에 저장된 데이터에 대한 액세스를 제어하기 위한 방법에 있어서,
    상기 복수의 캐시 파일들 중의 캐시 파일 내에 신규 버전의 특정 데이터 집합을 저장하는 단계로서, 각각의 캐시 파일은 일 버전의 데이터 집합을 저장하도록 구성된 것인, 상기 신규 버전의 특정 데이터 집합을 저장하는 단계;
    상기 캐시 파일 내에 상기 신규 버전의 특정 데이터 집합을 저장한 것에 응답하여, 상기 데이터 영역 내의 상기 신규 버전의 특정 데이터 집합의 주소에 대응하는 상기 제어 영역의 제1 버전 섹션 내에 저장된 키를 수정하는 단계;
    상기 데이터 영역 내의 상기 신규 버전의 특정 데이터 집합의 주소에 대응하는 상기 제1 버전 섹션 내에 저장된 키를 수정한 것에 응답하여,
    상기 제1 버전 섹션을 포인팅하여 상기 제1 버전 섹션을 현재 버전 섹션으로서 식별하도록 상기 제어 영역의 현재 옵셋을 수정하는 단계,
    제2 버전 섹션을 포인팅하여 상기 제2 버전 섹션을 과거 버전 섹션으로서 식별하도록 상기 제어 영역의 과거 옵셋을 수정하는 단계, 및
    제3 버전 섹션을 포인팅하여 상기 제3 버전 섹션을 신규 버전 섹션으로서 식별하도록 신규 옵셋을 수정하는 단계
    를 포함하는 데이터에 대한 액세스를 제어하기 위한 방법.
17. 삭제

Images