KR100310066B1 - 하부데이터에대한변경이캐시된오브젝트에어떻게영향을미치는지를결정하는방법 - Google Patents

Abstract

하부 데이터(underlying data)에 대한 변경들이 오브젝트들의 값에 어떻게 영향을 주는지에 관한 결정이 이루어질 수 있다. 애플리케이션들의 예들에는: 동적 웹 페이지들의 캐싱; 복수의 클라이언트들에게 (계속해서 변경되는)오브젝트들을 보내는 서버가 어느 클라이언트들에게 어느 버전들을 보내는지 그리고 그 버전들이 얼마나 낡았는지를 추적할 수 있게 하는 클라이언트-서버 애플리케이션들; 오브젝트들의 몇 개의 버전들을 유지 및 고유하게 식별하는 것, 낡은 오브젝트들을 갱신하는 것, 동일 오브젝트의 2개의 버전들이 얼마나 다른지를 정량적으로 평가하는 것, 및/또는 한 세트의 오브젝트들 사이에 일관성을 유지하는 것이 필요한 어떤 상황을 포함한다. 오브젝트 의존성 그래프라 불리는, 방향지시성 그래프(directed graph)는 오브젝트들간의 데이터 의존성들을 표시하는데 사용될 수 있다. 다른 측면은 캐시된 오브젝트와 원격 데이터에서의 변경을 연관시키기 위해 오브젝트들을 구축하고 유지하는 것이다. 만일 원격 데이터 소스에서의 데이터가 변경되면, 데이터 변경 통지들이 관련된 오브젝트들의 동적 재구성(rebuild)을 트리거(trigger)하는데 사용된다. 그리하여, 낡은 오브젝트들이 새로운 오브젝트들로 동적으로 대체될 수 있다. 오브젝트들은 동적 웹 페이지들과 같은 복합 오브젝트들 또는 혼성-복합 오브젝트들(compound-complex objects)일 수 있고 데이터는 데이터베이스에서의 하부 데이터일 수 있다. 갱신은 캐시에 오브젝트의 새로운 버전을 저장하거나 또는 캐시에서 오브젝트를 삭제하는 것의 어느 하나를 포함할 수 있다. 복수의 서버들 상의 캐시들은 단일의 공통 데이터베이스에서의 데이터와 또한 동기될 수 있다. 갱신된 정보는, 새로운 페이지들 또는 삭제된 오더(orders)인지에 관계없이, 한 세트의 서버 노드들로 방송될 수 있어서, 많은 시스템들이 동시에 프리페칭(prefetching)의 이점들을 누리도록 하고 높은 정도의 확장성(scaleability)을 제공한다.

Description

하부 데이터에 대한 변경이 캐시된 오브젝트에 어떻게 영향을 미치는지를 결정하는 방법(Determining How Changes to Underlying Data Affect cached Objects)

본 발명은 개선된 데이터 처리 시스템에 관한 것이다. 특히 월드 와이드 웹, 데이터베이스 및 트랜젝션 처리 시스템에 관한 것이다. 보다 구체적으로는 월드 와이드 웹 상에서 동적 서류(dynamic documents)의 캐싱에 관한 것이다.

월드 와이드 웹으로부터 서류들을 검색(retrieve)할 수 있는 속도는 웹이 정보를 전송하고 전자 상거래(electronic commerce)를 지원하는데 얼마나 유용한지를 나타내는 가장 중요한 요인들의 하나이다. 웹 서버는 신속하게 사용자에게 내용(content)을 제공할 수 있어야 한다. 웹 서버에 의해 전달되는 데이터는 2개의 카테고리로 분류될 수 있다.

(1) 정적 데이터 : 이 데이터는 컴퓨터 상에 저장된 파일들로부터 얻어진다. 정적 데이터는 상대적으로 신속하게 제공될 수 있다. 단일 RS/6000 590 노드와 같은 컴퓨터 상에서 운용되는 고-성능 웹 서버는 일반적으로 초당 수백 개의 파일들을 전달할 수 있다.

(2) 동적 데이터 : 이 데이터는 요구가 있을 때마다 프로그램을 실행함으로써 얻어진다. 동적 데이터는 생성하는데 종종 비용이 많이 든다. 많은 경우에, 동적 데이터는 정적 데이터에 비해 이를 획득하기 위한 비용이 수십 내지 수백 배가 된다.

동적 데이터를 높은 비율로 포함하는 웹 사이트에 있어서, 동적 데이터 성능이 장애(bottlenect)가 될 수 있다. 동적 데이터를 높은 비율로 포함하는 사이트들의 예에는 LL Bean 웹 사이트(www.llbean.com)와 IBM 1996 Olympics웹 사이트와 같은 IBM의 네트워크 상거래 소프트웨어를 사용하는 전자 상거래 사이트들이 포함된다.

동적 데이터의 오버헤드를 감소시키는 방법의 하나는 동적 데이터들이 프로그램에 의해 생성된 후 캐시에 동적 페이지들을 저장하는 것이다.(1996년 5월 분산 컴퓨팅 시스템을 위한 국제 회의록에서, Y.H. Liu, P.Dantzig, C.E.Wu, J.Challenger, L.M.Ni에 의한 "분산 웹 서버 및 복수 플랫폼 상에서의 그의 성능 분석(A Distributed Web Server and its Performance Analysis on Multiple Platforms)" 참조) 그 방법에서, 이들 페이지들을 액세스할 필요가 있는 후속 요구들은 캐시 내에 사본(copy)을 액세스할 수 있다. 페이지는 프로그램에 의해 한번만 산출되면 된다. 복수의 요구(request)에 응답하여 동일한 데이터를 여러 번 재-산출하는 오버헤드가 감소되거나 제거된다.

캐싱(caching)은 모든 동적 웹 페이지에 적용할 수는 없다. 어떤 동적 페이지는 페이지들이 요구될 때마다 상태 변경이 이루어져야 한다. 그러한 페이지들은 캐시될 수 없다.

캐시될 수 있는 페이지들에서도, 하나 이상의 웹 페이지들의 값에 영향을 줄 수 있는 하부 데이터에 대한 변경이 일어날 때 캐시를 갱신하는 방법에 대한 필요성이 있다. 예를 들어, 동적 웹 페이지는 종종 데이터베이스로부터 구축된다. 데이터베이스가 변경될 때, 데이터베이스 변경의 결과로 캐시 오브젝트가 낡았는지(obsolete)를 결정하는 것은 극히 어려울 수 있다. 본 발명은 이러한 문제에 대한 해결책을 제공한다. 해결책은 극히 일반적이며, 오브젝트들의 값에 영향을 미치는 하부 데이터에 대한 변경이 어떻게 이루어지는지를 알 필요가 있는 다른 상황들에도 사용될 수 있다.

하부 데이터의 소스 및 캐시들이 지역적으로 떨어져 있을 때 하나 이상의 캐시들의 세트를 어떻게 유지하는가는 다른 문제이다. 본 발명은 동적 및 정적 데이터 모두를 캐싱하는 프록시에 관련된 이 문제에 대한 해결책을 갖는다.

세 번째 문제는, 모든 갱신이 한꺼번에 이루어져서, 시스템에 의해 먼저 수신된 어떠한 요구도 나중에 수신된 요구 보다 갱신들에 관한 시스템의 보다 늦은 뷰(view)을 보지 않도록, 하나 이상의 캐시들에 대한 갱신들의 세트를 어떻게 일관성 있게 실행하는가이다. 본 발명은 정적 및 동적 데이터 모두를 캐싱하는 프록시에 관련된 일관성 문제에 대한 해결책을 갖는다. 또한 캐시들에 필연적으로 관련된 것이 아닌 트랜젝션 시스템에도 관련된다.

컴퓨터 프로그램을 만들기(build) 위해 필요한 파일들간에 의존성들(dependencies)을 관리하기 유틸리티(utilities)들이 이 기술 분야에 잘 알려져 있다. 예를 들어, 단일 프로그램이 복수의 자원 및 오브젝트 파일들로부터 만들어질 수 있다. 자원, 오브젝트, 실행가능한 파일들 사이에 의존성을 관리하기 위한 도구(tool)들이 개발되어 있다. 이러한 의존성을 관리하기 위한 가장 잘 알려진 유틸리티의 하나는 유닉스 'make' 커맨드이다(예를 들어, IBM AIX 버전 4 온-라인 매뉴얼 페이지를 참조).

'make'와 같은 유틸리티는 사용자에게 'makefile'로서 알려진 특수 파일에 파일들간의 의존성을 특정할 것을 요구한다. 예를 들어, "foo"가 "foo.h"와 "foo.c"에 의존함을 나타내기 위해서, 다음과 같은 파일 의존성 특정 문구:

foo:foo.h foo.c

cc -o foo foo.c

를 'makefile'에 둘 수 있다. "foo.h" 또는 "foo.c"에서의 변경은 "make foo"라는 커맨드가 다음 번에 제기될 때 커맨드 "cc -o foo foo.c"를 사용하여 "foo"를 재-컴파일하게 한다.

'makefile'과 같은 유틸리티들은 다음을 포함하는 몇 가지 제한을 갖는다.

(1) 'makefile'는 단지 파일들간에 특정되어야할 의존성만을 참작한다. 파일과 파일이 아닌 어떤 것 사이의 의존성들을 특정하는 것은 불가능하다. 캐시들에 저장될 수 있는 오브젝트들 및 캐시될 수 없는 (하부 데이터를 포함하는) 그래프 오브젝트들 사이에 특정되어야 할 의존성들을 참작하는 방법에 대한 필요성이 존재한다.

(2) 'makefile' 방식을 사용하면, 파일이 얼마나 낡았는지에 관계없이 'make' 커맨드에 의해 낡았음이 발견될 때마다 모든 파일들이 갱신된다. 낡은 오브젝트들을 언제나 갱신할 것을 요구하지 않는 방법에 대한 필요성이 또한 있다. 예를 들어, 약간 낡은 데이터가 캐시 내에 간직되도록 할 수 있다.

(3) 'makefile' 방식은 또한 한 번에 단지 한 버전의 파일만이 파일 시스템에 존재하도록 한다. 동시에 동일한 캐시에 동일 오브젝트들의 복수 버전들이 존재하도록 하는 방법에 대한 필요성이 또한 있다.

(4) 'makefile'과 같은 도구에 의해 제공되지 않는 것으로, 오브젝트가 얼마나 낡았는지를 결정하는 정량적인 방법에 대한 필요성이 있다.

(5) 'makefile'과 같은 도구들에 의해 제공되지 않는 것으로, 동일 오브젝트의 유사한 2개의 버전들이 얼마나 유사한지를 결정하기 위한 정량적인 방법에 대한 필요성이 있다.

(6) 'makefile'과 같은 도구들에 의해 제공되지 않는 것으로, 낡게 될 수 있는 오브젝트들의 일관성 있는 세트들을 간직하는 방법에 대한 필요성이 또한 있다.

(7) 'makefile'과 같은 도구들에 의해 제공되지 않는 것으로서, 관계 데이터베이스들의 일부일 수 있는, 관계 오브젝트들(relational objects)로 알려진 오브젝트들간에 의존성을 간결하게 특정하기 위한 방법에 대한 필요성이 있다.

본 발명은 이러한 필요성을 감안한 것이다. 많은 경우에, 오브젝트들의 값들은 하부 데이터에 의존하며, 본 발명은 하부 데이터에 대한 변경들이 오브젝트들의 값에 어떻게 영향을 미치는가를 결정하는 것을 제공한다.

도 1a는 본 발명의 특징들을 갖는 시스템의 일 예를 나타내는 도면.

도 1b는 본 발명의 특징들을 갖는 오브젝트 의존성 그래프의 일 예를 나타내는 도면.

도 1c는 본 발명의 특징들을 갖는 시스템의 일 예를 나타내는 도면.

도 2는 본 발명에 따라 사용되는 캐시의 일 예를 나타내는 도면.

도 3은 본 발명에 따라 사용되는 오브젝트 정보 블록(OJB)의 일 예를 나타내는 도면.

도 4는 본 발명에 따른 API 기능들의 일 예를 나타내는 도면.

도 5는 도 4의 API 기능들을 구현하는 방법을 나타내는 블록도.

도 6은 캐시에 오브젝트를 추가하는 API 기능을 나타내는 블록도.

도 7은 캐시에서 오브젝트를 찾는 API 기능을 나타내는 블록도.

도 8은 캐시로부터 오브젝트를 삭제하는 API 기능을 나타내는 블록도.

도 9는 레코드로부터 오브젝트로의 의존성을 추가하는 API 기능을 나타내는 블록도.

도 10은 레코드로부터 오브젝트로의 의존성을 삭제하는 API 기능을 나타내는 블록도.

도 11은 레코드가 변할 때 발동되는 API 기능을 나타내는 블록도.

도 12a는 본 발명의 특징들을 갖는 시스템의 다른 예를 나타내는 도면.

도 12b는 본 발명의 특징들을 갖는 오브젝트 의존성 그래프의 다른 예를 나타내는 도면.

도 12c는 도 12a의 오브젝트 관리자의 일 예를 나타내는 도면.

도 12d는 본 발명의 특징들을 갖는 오브젝트 의존성 그래프의 다른 예를 나타내는 도면.

도 13은 본 발명의 일 실시예에 따라 사용되는 캐시의 일 예를 나타내는 도면.

도 14는 본 발명에 따라 사용되는 오브젝트 정보 블록(OIB)의 일 예를 나타내는 도면.

도 15는 본 발명에 따라 사용되는 의존성 리스트의 일 예를 나타내는 도면.

도 16은 본 발명에 따라 사용되는 의존성 정보 블록(DIB)의 일 예를 나타내는 도면.

도 17은 본 발명에 따른 API 기능들의 다른 예를 나타내는 도면.

도 18은 도 17에서 API 기능들을 구현하는 방법을 나타내는 블록도.

도 19는 캐시에 오브젝트의 최신 버전을 추가하는 캐시 API 기능을 나타내는 블록도.

도 20은 하나의 캐시에서 다른 캐시로 오브젝트의 버전의 복사를 시도하는 API 기능을 나타내는 블록도.

도 21은 하부 데이터가 변할 때 발동될 수 있는 API 기능을 나타내는 블록도.

도 22는 하부 데이터에 대한 변경들에 응답하여 오브젝트 의존성 그래프를 통해 변경들을 전파하는 방법의 일부를 나타내는 블록도.

도 23은 하부 데이터에 대한 변경들에 응답하여 깊이-우선(depth-first) 방식으로 오브젝트 의존성 그래프를 통해 변경들을 전파하는 방법의 일부를 나타내는 블록도.

도 24는 하부 데이터에 대한 변경들에 응답하여 특정 그래프 오브젝트로 변경들을 전파하는 방법의 일부를 나타내는 블록도.

도 25는 하부 데이터에 대한 변경들에 응답하여 오브젝트의 캐시된 버전으로 변경들을 전파하는 방법의 일부를 나타내는 블록도.

도 26은 하부 데이터에 대한 변경들에 응답하여 하나 이상의 캐시들에 하나 이상의 오브젝트들을 추가할 때 일관성을 유지하는 방법의 일부를 나타내는 블록도.

도 27은 단일 레코드 오브젝트(SRO)들에 상응하는 그래프 노드들을 생성하는 캐시 API 기능을 나타내는 블록도.

도 28은 복수의 레코드 오브젝트(MRO)들에 상응하는 그래프 노드들을 생성하는 API 기능을 나타내는 블록도.

도 29a는 레코드들이 변할 때 발동될 수 있는 API 기능을 나타내는 블록도.

도 29b는 오브젝트 의존성 그래프의 또 다른 예와 그것이 그래프 오브젝트들로 변경들을 전파하는데 어떻게 사용되는지를 나타내는 도면.

도 30a는 캐시들을 확대 축소 가능하게 유지하고 일관되게 갱신하는 본 발명의 특징들을 갖는 시스템의 예를 나타내는 블록도.

도 30b는 마스터 트리거 모니터로서 예시되는 도 30a의 트리거 모니터의 보다 구체적인 예를 나타내는 도면.

도 30c는 슬래이브 트리거 모니터로 예시되는 트리거 모니터의 일 예를 나타내는 도면.

도 30d는 도 30b의 송신_트리거 API의 일 예를 나타내는 도면.

도 30e는 본 발명에 따른 트랜젝션 형태들의 예들을 나타내는 도면.

도 31은 도 30b의 오브젝트 배열 블록(ODB)의 일 예를 나타내는 도면.

도 32는 도 31의 캐시 ID의 일 예를 나타내는 도면.

도 33은 트리거 모니터 드라이버와 배열 관리자의 하이-레벨 조직 및 통신 경로들의 일 예를 나타내는 도면.

도 34는 도 33의 수신 스레드 로직의 일 예를 나타내는 도면.

도 35는 도 33의 인입 작업 디스패처 스레드 로직의 일 예를 나타내는 도면.

도 36은 도 33의 캐시 관리자 통신 스레드 로직의 일 예를 나타내는 도면.

도 37은 도 33의 오브젝트 발생기 스레드 로직의 일 예를 나타내는 도면.

도 38은 도 33의 분배 관리자 스레드 로직의 일 예를 나타내는 도면.

도 39는 도 33의 아웃바운드 트랜젝션 스레드 로직의 일 예를 나타내는 도면.

도 40은 트리거 이벤트의 분석 및 트랜젝션을 위한 확장 및 변형들의 예들을 나타내는 도면.

도 41은 하나 이상의 캐시들로 구성되는 시스템에 일관되게 한 세트의 요구들을 하는 로직의 일 예를 나타내는 도면.

도 42는 요구를 수신하는 캐시 관리자들의 세트들이 복수의 멤버들을 가지면 최후_잠금_시간(last_lock_time)을 결정하는 로직의 일 예를 나타내는 도면.

<도면의 주요 부분에 대한 부호의 설명>

1…캐시 관리자

2…캐시

3…디렉토리

4…오브젝트 저장소

5…보조 상태 정보

6…오브젝트

8…오브젝트 리스트

9…오브젝트 ID

10…오브젝트 정보 블록

11…레코드 리스트

12…레코드 ID

90…클라이언트

95…네트워크

97…애플리케이션

100…서버

본 발명의 일 예로서, 데이터베이스들로부터 동적으로 페이지들이 생성되는 웹 사이트를 고려한다. 이 상황에서, 동적 웹 페이지는 오브젝트들이며 하부 데이터는 데이터베이스들을 포함한다. 어떤 경우에, 웹 페이지는 보다 단순한 웹 페이지에 대한 의존성을 가질 수 있으며, 보다 단순한 웹 페이지 또한 데이터베이스에 대한 의존성을 갖는다. 오브젝트들이 다른 오브젝트들을 의존하고 그것들이 또한 다른 오브젝트들에 의존하게 되는 의존성들의 전체적인 계층구조를 갖는 것이 가능하다. 세트 내에 어떤 오브젝트에 대한 갱신이 그 세트 내에 다른 모든 오브젝트들의 값에 영향을 주는 한 세트의 오브젝트들간의 상호-의존성을 갖는 것이 또한 가능하다.

본 발명의 또 다른 측면은, 컴퓨터 시스템으로 하여금 하부 데이터 변경 후 시스템 내의 모든 오브젝트들로 갱신들을 전파하도록 하는 하부 데이터와 오브젝트들간의 의존성들을 특정하기 위한 방법을 제공한다. 이 방법은 다음과 같은 특징들을 하나 이상 포함한다:

1. 오브젝트들이 다른 오브젝트들을 의존할 수 있고 그 다른 오브젝트들이 또한 다른 오브젝트들을 의존하는 등과 같은 계층적 형식으로 의존성들이 특정될 수 있다.

2. 오브젝트들의 세트들은 상호-의존성들을 가질 수 있다. 예를 들어, 2개의 오브젝트들은 상호간에, 그들 중 하나의 값이, 다른 오브젝트가 변경될 때마다 변경됨을 나타내는, 상호간의 의존성을 가질 수 있다.

3. 의존하고 있는 임의의 하부 데이터에 대한 변경이 일어날 때마다 오브젝트가 갱신(또는 무효화)됨을 확인하는 방법.

4. 오브젝트의 낡은 버전이 현행 버전과 얼마나 다른지를 결정하기 위한 정량적 방법.

5. 현행 버전과 충분히 다를 때마다 오브젝트가 갱신(또는 무효화)됨을 확인하는 방법. 이 방법은 현행 오브젝트가 너무 많은 오버헤드를 수반함이 항상 유지될 때 유용하다.

새로운 버전의 오브젝트는 그 값이 재 산출될 때마다 생성된다. 동일 오브젝트의 복수의 버전들이 간직될 수 있다. 동일 오브젝트의 2개의 사본들에 대해서,

(a) 만일 2개의 오브젝트들이 동일 버전에 상응하면, 2개의 오브젝트는 동일하다고 결정되고;

(b) (a)의 대답이 '아니오'이면, 어느 버전이 보다 현대화된 것인지(즉, 보다 나중에 생성된 것인지)가 결정되며;

(c) (a)의 대답이 '아니오'이면, 오브젝트들이 얼마큼 다른지에 대한 정량적 표시가 결정된다.

7. 모든 오브젝트들을 현대화할 필요 없이 한 세트의 오브젝트들의 일관성을 유지하는 방법. 이 방법은 모든 오브젝트들의 현대화를 요구함으로써 일관성을 확보하는 것이 너무 높은 오버헤드를 가질 수밖에 없는 경우에 유용하다.

8. 관계 오브젝트들간에 내재적 데이터 의존성들이 오브젝트 관리자에 의해 자동적으로 추가되는 관계 오브젝트들을 관리하는 방법.

본 발명의 애플리케이션들의 예들은 다음 상황들을 포함한다:

1. 동적 웹 페이지들의 캐싱

2. 클라이언트-서버 애플리케이션들: 많은 클라이언트-서버 애플리케이션들에서, 서버는 복수의 클라이언트들에게 오브젝트들을 송신할 것이다. 오브젝트들은 항상 변한다. 동일 오브젝트의 다른 버전들은 오브젝트가 요구된 시점에 따라 다른 클라이언트들에게 송신될 수 있다. 서버는 어느 버전들이 어느 클라이언트들에게 송신되며 그 버전들이 얼마큼 낡은 것인지를 추적하기 위한 어떤 방법을 필요로 한다.

3. 몇몇 버전들의 오브젝트들을 유지하고, 그들을 고유하게 식별하고, 그들이 너무 낡게 되면 그들을 갱신하고, 동일 오브젝트의 2개의 다른 버전들이 얼마큼 다른지를 정량적으로 평가하고, 및/또는 한 세트의 오브젝트들간에 일관성을 유지하는 것이 필요한 어떤 상황.

바람직한 실시예는 오브젝트들간의 데이터 의존성들을 나타내는 '오브젝트 의존성 그래프(G)'라 불리는 방향지시성 그래프(directed graph)를 사용한다. 오브젝트(o1)에서 다른 오브젝트(o2)로의 엣지(edge)는 o2가 o1에 대한 의존성을 가짐을 의미한다. o1에 대한 어떤 갱신은 또한 o2의 현행 값을 변경한다. 다른 실시예에서, 각 엣지는 데이터 의존성의 중요도를 나타내는 웨이트로 알려진 그에 관련된 음이 아닌 수(non negative number)를 가질 수 있다. 예를 들어, 낮은 수들이 무의미한 의존성들을 나타내는데 반하여, 높은 수들은 중요한 의존성들을 나타낼 수 있다. 오브젝트들은 그들에 관련된 '임계_웨이트'로 알려진 값을 가질 수 있다. 현행하는 인입 데이터 의존성(incoming data dependence)들에 상응하는 웨이트들의 합이 임계_웨이트 아래로 떨어질 때마다, 오브젝트는 매우 낡은 것으로 간주된다. 그러한 오브젝트들은 오브젝트들의 최근 버전들을 요구하는 애플리케이션들을 위해 갱신되어야만 한다. 각 오브젝트는 바람직하게는 'object_id' 필드 및 'version_number' 필드를 갖는다.'object_id' 필드는 애플리케이션 프로그램이 오브젝트를 식별하기 위해 사용하는 어떤 것(예를 들어, URL)에 상응하며, 'version_number' 필드는 동일 'object_id'를 갖는 복수의 오브젝트들이 유지되고 고유하게 식별되는 것이 가능하게 한다.

더욱 구체적으로, 오브젝트 관리자로서 알려진 프로세스는 데이터 의존성 정보를 관리한다. 새로운 오브젝트들이 생성되거나 데이터 의존성들이 변할 때마다, 오브젝트 관리자는 적합한 정보를 갱신할 책임이 있다. 오브젝트가 갱신될 때마다, 오브젝트 관리자는 데이터 의존성들에 의해 요구되는 시스템에 대한 다른 갱신들을 전파하기 위하여 오브젝트 의존성 그래프에서의 정보를 사용한다.

각 오브젝트 o1도 또한 o1과 일관성이 있어야 하는 오브젝트들의 리스트를 포함하는 '일관성 리스트'를 가질 수 있다. 2개의 오브젝트들 o1 및 o2는:

(1) 양 오브젝트들이 현행하거나; 또는

(2) 과거의 어느 시점에서, 양 오브젝트들이 현행하였다면, 일관성이 있다.

o1에 대한 갱신은 또한 o1에 대한 일관성 리스트 상의 다른 오브젝트들에 대한 갱신들을 필요로 할 수 있다.

관계 데이터베이스에서의 관계들에 유사한 관계들에 속하는 하나 이상의 레코드들에 오브젝트를 관련시키는 것이 가능하다. 이러한 오브젝트는 관계 오브젝트로 알려져 있다. 본 발명은 또한 관계 오브젝트들간에 의존성들을 자동으로 추가하는 특징을 갖는다.

하부 데이터에 대한 변경들이 캐시된 오브젝트들에 어떻게 영향을 미치는지를 결정하는 방법에 대한 상세한 설명.

용어의 설명

사전적인 의미들이 여기서 사용되는 용어들에도 또한 포함되지만, 몇몇 용어들의 다음 해설은 유용할 것이다:

'캐시'는 저장 영역이다. 그것은 메모리 내, 디스크 상, 또는 일부는 메모리 내이고 일부는 디스크 상에 있을 수 있다. 캐시에 상응하는 물리적 또는 가상적 어드레스들이 고정될 수 있다. 한편, 그들은 시간에 걸쳐서 변할 수 있다. 캐시들의 정의는 다음을 포함하나 이에 한정되지는 않는다:

-IBM 인터넷 연결 서버 내의 프록시 캐시 또는 네스케이프 네비게이터 내의 브라우저 캐시와 같은 웹 서류를 위한 캐시들;

-IBM의 DB2 데이터베이스와 같은 데이터베이스 캐시들;

-컴퓨터들의 IBM RS/6000 라인에서의 프로세서 캐시들과 같은 프로세서 캐시들; 및

-적어도 어떤 데이터를 위해, 저장 리포지토리 프로그램이 데이터가 저장되어 있는 곳의 가상적 또는 물리적 어드레스들을 명시적으로 제어하지 않는, 하이-레벨 프로그래밍 언어로 쓰여진 데이터를 위한 저장 리포지토리(repository)들.

캐시 연합(union)은 시스템 내의 모든 캐시들의 조합이다.

오브젝트는 하나 이상의 캐시들 내에 저장될 수 있는 데이터이다.

복수 버전 캐시는 동일 오브젝트의 복수 버전들을 포함할 수 있는 캐시이다.

단일 버전 캐시는 동일 오브젝트의 단지 하나의 버전만을 포함할 수 있는 캐시이다.

현행 버전 캐시는 어떤 캐시된 오브젝트의 버전이 현재 통용되는 것이어야 하는 단일 버전 캐시이다.

하부 데이터(underlying data)는 하나 이상의 오브젝트들의 값에 영향을 미치는 시스템 내의 모든 데이터를 포함한다. 하부 데이터는 시스템 내에 모든 오브젝트의 슈퍼세트(superset)이다.

복합 오브젝트(complex object)는 하부 데이터에 대한 하나 이상의 의존성을 갖는 오브젝트이다.

오브젝트 관리자는 하부 데이터에 대한 변경들이 오브젝트들의 값들에 어떻게 영향을 미치는지를 결정하는 프로그램이다.

그래프 G=(V,E)는 노드들로도 또한 알려진 꼭지점들의 유한하고 비어있지 않은 세트 V와 꼭지점들의 쌍들로 구성되는 엣지들의 세트 E로 구성된다. 엣지들이 꼭지점들의 순서쌍(v, w)들이면, 그래프는 v가 엣지의 소스이고 w가 엣지의 목표로 지정되었다고 한다.

멀티그래프(multigraph)는 그래프와 유사하다. 주요한 차이는 꼭지점들의 쌍들간에 복수의 엣지들이 존재한다는 것이다. 멀티그래프는 그래프들의 슈퍼세트이다.

웨이티드 그래프(weighted graph) 또는 웨이티드 멀티그래프(weighted multigraph)는 그와 관련된 웨이트로 알려진 수를 각 엣지가 선택적으로 가질 수 있는 것이다.

오브젝트 의존성 그래프는 방향지시성 멀티그래프(directed multigraph)이다. 오브젝트 의존성 그래프의 꼭지점들은 그래프 오브젝트들로 알려져 있다. 그래프 오브젝트들은 오브젝트들의 슈퍼세트이고 다음을 포함할 수 있다:

(1) 오브젝트들;

(2) 오브젝트들이 아닌 하부 데이터; 및

(3) 가상 오브젝트들.

이들 그래프 오브젝트들은 실제 데이터에 상응하지 않는다. 그들은 데이터 의존성들을 전파하는 도구(convenience)로서 사용된다. 가상 오브젝트들은 (1) 및 (2)만큼 자주 사용되지 않는다.

그래프 오브젝트 o1에서 o2로의 엣지는 o1에서 o2로의 데이터 의존성(또한 의존성 또는 의존도라 함)을 나타낸다. 이는 o1에 대한 변경이 또한 o2를 변경할 수 있음을 의미한다. 의존성들은 추이적(推移的)(transitive)이다. 따라서, a가 b에 대해 데이터 의존성을 가지고 b가 c에 대해 데이터 의존성을 가지면, a는 c에 대해 데이터 의존성을 갖는다.

그래프 오브젝트는 또한 관계 오브젝트(RO)일 수 있다. RO들은 그들과 제휴한 관계 특정자(relational specifier)를 갖는다. RO의 2개의 예들은 다음과 같다.

1. 단일 레코드 오브젝트(SRO)들; 관계 특정자는 단일 레코드를 나타낸다.

2. 복수 레코드 오브젝트(MRO)들; 관계 특정자는 복수 레코드들을 나타낸다.

r2에 의해 표시되는 모든 레코드들이 또한 r1에 의해 표시되면 RO rl은 RO r2를 포함한다.

노드 v에 대한 발신 인접도 리스트(outgoing adjacency list)는 엣지 (v, w)가 E에 포함되도록 하는 노드 w 모두를 포함하는 리스트이다.

노드 v에 대한 인입 인접도 리스트(incoming adjacency list)는 엣지 (w, v)가 E에 포함되도록 하는 노드 w 모두를 포함하는 리스트이다.

리프 노드(leaf node)는 어떤 노드들의 목표가 아닌 노드이다.

적당한 리프 노드는 적어도 하나의 엣지의 소스인 리프 노드이다.

최고 노드(maximal node)는 어떤 노드들의 소스가 아닌 노드이다.

적당한 최고 노드는 적어도 하나의 엣지의 목표인 최고 노드이다.

단순 의존성 그래프는 각 노드가 리프 노드 또는 최고 노드인 방향지시성 그래프(directed graph)이다.

2개의 오브젝트들 o1 및 o2는:

(1) 양 오브젝트들이 현행되거나, 또는

(2) 과거의 어느 시간 t에, 양 오브젝트들이 현행되었다면, 일관성이 있다.

버전 번호는 동일 오브젝트들의 다른 버전들이 고유하게 식별되도록 하는 데이터이다. 하나의 구현예에 따르면, 버전 번호들을 위해 정수들을 사용하고 새로이 생성된 현행 버전에 이전 버전 번호에 1을 가산한 버전 번호를 할당한다. 그러나, 다른 구현예가 또한 가능하며, 버전 번호들은 반드시 수들일 필요는 없다.

예를 들어, 버전 번호들을 구현하는데 문자열(text strings)을 또한 사용할 수 있다.

오브젝트의 최신 버전은 현행 버전으로 알려져 있다.

이제 도면들을 참조하면, 도 1a는 본 발명의 특징들을 갖는 클라이언트-서버 구성(architecture)의 일 예를 나타낸다. 도시된 바와 같이, 클라이언트(90)는 네트워크(95)를 통해서 서버(100)로 요구를 통신한다. 서버(100)는 하나 이상의 캐시들(2)을 유지한다. 알려진 바와 같이, 서버(100)는 클라이언트(90)의 요구들을 충족하기 위한 CPU 시간을 줄이고 성능을 향상시키기 위해 캐시들(2)을 사용한다. 도 1a가 단일 서버에 연관된 캐시들(2)을 나타내고 있으나, 캐시들(2)은 복수의 서버들에 걸쳐서도 또한 유지될 수 있다. 이 기술 분야의 숙련자는 클라이언트-서버 기반이 아닌 다른 애플리케이션을 위해서도 또한 본 발명을 용이하게 개조(adapt)할 수 있다.

서버(100) 상에서 실행되는 애플리케이션 프로그램(97)은 오브젝트들을 생성하고 그들 오브젝트들(예를 들어, 그를 위한 요구들에 따른 상태 변경들을 일으키지 않는 동적 페이지들)을 하나 이상의 캐시들(2) 상에 저장한다. 서버(100)는 또한, 캐시(2)와 데이터베이스(99) 내의 하부 데이터의 소스가 지리적으로 떨어져 있는 프록시 서버일 수 있다. 오브젝트들은 데이터베이스(99) 상에 저장된 하부 데이터로부터 구성될 수 있다. 하부 데이터는 캐시(2) 내에 저장된 하나 이상의 오브젝트들의 값에 영향을 미치는 시스템 내의 모든 데이터를 포함한다. 하부 데이터는 시스템 내의 모든 오브젝트들의 슈퍼세트이다. 복합 오브젝트는 하부 데이터에 대한 하나 이상의 의존성들을 갖는 오브젝트들이다.

또한, 모든 캐시 연합 내의 캐시들(2)을 현행 버전 캐시들이라 한다. 현행 버전 캐시는 어떤 캐시된 오브젝트의 버전이 현행되어야만 하는 단일 버전 캐시이며, 단일 버전 캐시는 동일 오브젝트의 단지 하나의 버전만이 허여되는 캐시임을 상기하여야 한다.

본 발명에 따르면, 캐시 관리자(1)(오브젝트 관리자의 일 예임)는 하부 데이터에 대한 변경들이 오브젝트들의 값들에 얼마큼 영향을 미치는지 결정한다. 도 1a가 단일 서버 상에 상주하는 캐시 관리자(1)를 나타내고 있으나, 그것은 또한 복수 서버들에 걸쳐서도 분포할 수 있다. 캐시 관리자(1)는 바람직하게 서버(100)(또는 클라이언트(90))와 같은 컴퓨터 상에서의 실행을 위한 프로그램 저장소 상에 유형적으로 구체화되는 컴퓨터 실행가능한 코드로서 구체화될 수 있다. 이 기술 분야의 숙련자는, 본 발명에 따라, 캐시(2), 캐시 관리자(1), 및 데이터베이스(99)는 마찬가지로 클라이언트(90)에 관련될 수 있음을 알 수 있다.

캐시 관리자(1)는 하부 데이터, 예를 들어, 데이터베이스 레코드들, 캐시된 오브젝트가 의존하는 것을 특정하기 위한 API들(도 4)을 제공한다. 캐시 관리자(1)는 이들 의존성들을 추적한다. 프로세스가 캐시 내에 복합 오브젝트의 값들에 영향을 미칠 수 있는 상태를 수정(modify)할 때마다, 프로세스는 그것이 갱신하는 하부 데이터를 특정한다. 캐시 관리자는 그 때 갱신되고 있는 하부 데이터를 의존하는 캐시된 오브젝트들을 모두 무효화한다.

도 1b는 본 발명의 특징들을 갖는 오브젝트 의존성 그래프(G)(121')의 일 예를 나타낸다. 이 실시예에서의 오브젝트 의존성 그래프(G)(121')는 다른 실시예(도 12b)에서 보다 덜 복잡함을 주목하여야 한다. 여기서, 오브젝트 의존성그래프(G)(121')는 단순 의존성 그래프, 즉 각 노드가 리프 노드(r1, ..., r3) 또는 최고 노드(co1, co2)인 방향지시성 그래프(directed graph)이다. 리프 노드는 임의의 엣지의 목표가 아닌 노드이고 최고 노드는 임의의 엣지의 소스가 아닌 노드임을 상기하여야 한다. 또한 모든 경로가 길이가 1이고 엣지들을 위한 웨이트들을 특정할 필요가 없음을 주목하여야 한다. 또한, 각각의 적당한 최고 노드(적어도 하나의 엣지의 목표인 최고 노드)(co1, co2)는 오브젝트이고; G에서 각각의 적당한 리프 노드(r1, ..., r4)(적어도 하나의 엣지의 소스인 리프 노드)는 오브젝트가 아닌 하부 데이터를 나타낸다. 하부 데이터는 레코드로서 언급된다.(이들 레코드들은 제2 실시예에서 사용되는 레코드들과 동의어가 아니다.) 적당한 최고 노드들(co1, co2)에 의해 표시되는 오브젝트들은 복합 오브젝트들이다.

캐시 관리자(1)는 오브젝트 의존성 그래프(G)(121')를 나타내는 하부 데이터 구조들(도 2 내지 도 3 참조)을 유지한다. 애플리케이션 프로그램들(97)은 캐시들 API들의 세트를 통해서 캐시 관리자(1)로 오브젝트 의존성 그래프들의 구조를 통신한다(도 4 참조). 애플리케이션은 또한 오브젝트 관리자(1)에게 변경되는 레코드들(r1, ..., r4)을 통지하기 위해 API들을 사용한다. 캐시 관리자(1)가 레코드들(r1, ..., r4)에 대한 변경들을 통지 받으면, 영향을 받는 복합 오브젝트들(co1, co2)이 어느 것인지를 식별하고 식별된 복합 오브젝트들을 그들을 포함하는 임의의 캐시들(2)로부터 삭제(또는 갱신)되도록 하여야 한다. 캐시 관리자(1)는 G 내에 엣지들을 검사함으로써 어느 복합 오브젝트들이 변화하였는지를 결정할 수 있다(도 11 참조).

예를 들어, 캐시 관리자(1)에게 r1이 변화하였음이 통지되었다고 하자. 그래프(G)(121')는 co1 또한 변화하였음을 의미한다. 캐시 관리자(1)는 그것을 포함하는 임의의 캐시들(2)로부터 co1이 삭제(또는 갱신)됨을 확인하여야만 한다. 다른 예로서, r2가 변화하였다고 가정하자. 그래프(G)(121')는 co1 및 co2가 또한 영향을 받았음을 의미한다. 여기서, 캐시 관리자는 co1 및 co2 모두가 그들을 포함하는 임의의 캐시들(2)로부터 삭제(또는 갱신)됨을 확인하여야만 한다.

다른 말로 하면, 기본적 방식은 그들이 레코드들의 세트에 의존하도록 애플리케이션 레벨에서 복합 오브젝트들을 구축하는 것이다. 애플리케이션은 복합 오브젝트(co1,co2)가 어느 레코드들(r1, ..., r4)을 의존하는지를 특정할 수 있어야만 한다. 캐시된 복합 오브젝트의 값에 영향을 줄 수 있는 방식으로 상태를 수정하는 모든 프로세스에 대해서, 애플리케이션 프로그램은 어느 레코드들이 영향을 받는지를 특정할 수 있어야만 한다. 이 형태의 복합 오브젝트들은 정상 형태(normal form)라고 한다. 이미 존재하는 많은 웹 애플리케이션들은 정상 형태로 이미 존재하는 캐시 가능한 복합 오브젝트들을 생성한다. 이들 애플리케이션들에서 캐싱을 사용하기 위하여, 단지 복합 오브젝트들의 하부에 있는 레코드들을 인식하고 제공되는 API들을 통해서 캐시로 애플리케이션을 인터페이스하는 것만이 필요하다. 애플리케이션들에 대한 다른 변경들은 필요하지 않다.

바람직하게는, 캐시 관리자(1)는 하나 이상의 캐시들(2)을 위한 저장소(storage)를 관리하는 장기 실행 프로세스(long running process)이다. 그러나, 이 기술 분야의 숙련자는 다음의 하나인 캐시 관리자를 위해 본 발명을 용이하게 개조할 수 있다:

1. 어느 것도 시간상 중복되지 않는, 복수의 개별 프로세스들(multiple distinct processes).

2. 일부가 시간상 중복되는 복수의 개별 프로세스들. 이는 캐시 시스템의 스루풋(throughput)을 향상시키도록 고안된 복수의 동시실행 캐시 관리자들을 포함한다.

도 1c는 동적 웹 페이지를 캐싱하기 위한 본 발명에 따른 시스템의 일 예를 나타낸다. 도시한 바와 같이, 페이지들(page 1, ..., page 5)이 하나 이상의 데이터베이스들(99)로부터 동적으로 생성되고 하나 이상의 캐시들(2)에 저장되는 종래의 웹 사이트(100)를 고려한다. 본 발명에 적용 가능한 데이터베이스(99) 및 데이터베이스 관리 시스템의 일 예는 상표명 DB2로 IBM사에 의해 판매되는 것이다. 여기서, 동적 웹 페이지들(page 1, ..., page 5)은 오브젝트들이고 하부 데이터(테이블들/레코드들)는 데이터베이스(99)의 부분들을 포함한다.

본 발명에 따르면, 캐시 관리자(1)는 애플리케이션 프로그램(97)으로 하여금 캐시된 오브젝트가 의존하는 레코드들을 특정하도록 하는 API들(도 4)을 제공한다. 캐시 관리자(1)는 이들 의존성들을 추적한다. 애플리케이션 프로그램(97)이 레코드(들)을 수정하거나 또는 캐시 내의 복합 오브젝트들의 값에 영향을 줄 수 있는 레코드에 대한 변경들에 관해서 알려고 할 때마다, 애플리케이션 프로그램(97)은 갱신이 이루어진 레코드(들)을 캐시 관리자(1)로 통지한다. 캐시 관리자(1)는 그 때 변경된 레코드(들)에 대한 의존성을 갖는 캐시된 오브젝트들을 모두 무효화하거나 또는 갱신한다.

예를 들어, 도 1c에 도시된 HTML 페이지들(page 1, ..., page 5)을 고려하자. 복합 오브젝트들인 HTML 페이지들은, 데이터베이스(99)로부터 구축되어 캐시 내에 저장된다. 각각의 HTML 페이지는 Table1, Table2, ..., Table6으로 표시되는 데이터베이스의 부분들인 하나 이상의 레코드들에 대한 의존성을 가질 수 있다. 테이블들과 페이지들간에 상응은 해시 테이블(hash table)들 및 레코드 리스트들(19)에 의해 유지될 수 있다. 예를 들어, 캐시 관리자(1)가 Table1(T1)에 대한 변경을 통지 받으면, Page1, Page2 및 Page3을 무효화(또는 갱신)할 것이다.

도 2는 캐시(2)의 일 예를 나타낸 것이다. 도시된 바와 같이, 각각의 캐시(2)는 바람직하게는 해시 테이블 엔트리들(25)에 4개의 저장 영역들, 즉 각각의 캐시된 오브젝트에 관한 정보를 유지하는 디렉토리(3)와; 오브젝트들(6)을 저장하기 위한 오브젝트 저장소(4)와; 다른 상태 정보(예를 들어, 캐시에 의해 유지되는 통계들)를 포함하는 보조 상태 정보(5)와; 레코드들에 관한 정보를 저장하는 해시 테이블(19)을 갖는다.

바람직한 실시예에서, 해시 테이블 엔트리들(25)은 레코드 ID들(12); 및 오브젝트들의 리스트, 즉 그 값들이 데이터베이스(99)의 일부일 수 있는 레코드에 의존하는, 오브젝트 id(들)(9)을 포함하는 오브젝트 리스트들(8)을 구비한다. 그러나, 본 발명은 또한 다른 종류들의 정보가 해시 테이블 엔트리들 내에 저장되도록 할 수도 있다. 해시 테이블의 목적은 특별한 테이블/레코드에 관한 정보를 찾기 위한 효율적인 방법을 제공하는 것이다. 바람직한 해싱은 레코드 ID(12)에서 열쇠를 찾을 수 있다. 해시 테이블들은 이 기술분야에서 잘 알려져 있다(예를 들어, Aho, Hopcroft, Ullman, Addison-Wesley, 1974년의 "The Design and Analysis of Computer Algorithms(컴퓨터 알고리즘의 디자인 및 분석)"을 참조). 해시 테이블들은 본 발명을 위한 효율적인 데이터 구조를 제공한다. 그러나, 본 발명은 매우 다양한 다른 데이터 구조들과도 양립할 수 있으며 해시 테이블들을 사용하는 것으로 제한되지 않는다.

디렉토리(3)는 캐시 내에 저장된 각각의 오브젝트(6)를 위한 오브젝트 정보 블록(OIB)을 포함한다. OIB(10)의 콤포넌트의 하나는 복합 오브젝트(co1, co2)와 연관된 레코드들(r1, ..., r4)을 식별하는 레코드 ID들(12) 모두를 저장하는데 사용되는 레코드 리스트(11)(도 3)이다. 여기서, 복합 오브젝트들은 캐시(2) 내에 저장된 동적 웹 페이지들(page 1, ..., page 5)이고 레코드들은 데이터베이스(99)의 일부일 수 있다. 바람직한 실시예는 레코드 ID들에 대해 문자열을 사용하였으나 다른 방법들도 또한 사용될 수 있다.

애플리케이션 프로그램은 API 기능들의 세트를 통해서 캐시 관리자(1)와 통신한다. 본 발명에 따른 API들의 예들을 도 4에 나타내었다. 이 기술분야의 숙련자들은 본 발명의 사상 및 범주 내에서 단순한(straightforward) 방식으로 구현할 수 있다. 도시된 바와 같이, API들의 예들은:

Cache_object(object_id, object, cache_id)(410) : 키 object_id(9) 하의 cache_id에 의해 식별되는 캐시(2)(도 2)에서 cache_id에 의해 식별되는 오브젝트(6)를 저장하고; 동일 키를 갖는 임의의 이전 오브젝트(6)를 덮어쓴다. 본 발명은 object_id, object 및 cache_id에 대한 매우 다양한 형태들과 양립할 수 있다. 바람직한 실시예에서, 오브젝트(6)는 몇 가지의 형태일 수 있으며, object_id는 바이트열이고, cache_id는 문자열이다. 여기서, 동일 키를 갖는 복수의 항목들이 동시에 동일 캐시 내에 존재하지 않도록 하는 것이 바람직하다. 그러나, 동일 키를 갖는 복수의 항목들이 동시에 동일 캐시 내에 존재할 수 있는 상황에도 본 발명을 사용하는 것은 이 기술 분야의 숙련자에게는 용이할 것이다.

Lookup_object(object_id, cache_id)(145): 캐시(2)에서 키 object_id(9)를 갖는 cache_id에 의해 식별된 오브젝트(6)를 찾는다. 그러한 오브젝트(6)가 존재하면, 그것을 애플리케이션 프로그램으로 리턴시킨다.

Delete_object (object_id, cache_id)(420): 캐시에서 키 object_id (9)를 갖는 cache_id에 의해 식별되는 오브젝트(6)를 찾는다. 만일 그러한 오브젝트(6)가 존재하면, 그것을 삭제한다.

add_object(object_id, cache_id, record_id)(430): cache_id에 의해 식별되는 캐시(2) 내에서 키 object_id(9)를 갖는 오브젝트(6)를 찾는다. 그러한 오브젝트(6)가 존재하고 record_id에 연관된 record_id(12)에 의해 식별된 레코드와 오브젝트(6)간의 의존성이 없으면, 의존성을 추가한다.

delete_dependency(object_id, cache_id, record_id)(440): cache_id에 의해 식별된 캐시에서 키 object_id(9)를 갖는 오브젝트(6)를 찾는다. 만일 그러한 오브젝트(6)가 존재하고 오브젝트(6)와 record_id(12)에 의해 식별되는 레코드간에 의존성이 있으면, 의존성을 삭제한다.

Invalidate_record(cache_id, record_id)(450): cache_id에 의해 식별되는 캐시(2)로부터 record_id에 의해 식별되는 레코드에 의존하는 모든 캐시 오브젝트들을 삭제한다.

Show_dependent_objects(cache_id, record_id)(460): record_id에 의해 식별되는 레코드에 의존하는 cache_id에 의해 식별되는 캐시(2) 내의 모든 오브젝트들을 위한 object_id들(9)의 리스트를 리턴한다. 이 기능은 record_id에 의해 식별되는 레코드에 상응하는 해시 테이블 엔트리(25)를 위한 오브젝트 리스트(8)를 리턴함으로써 구현될 수 있다. 상태 변수는 또한 캐시(2) 또는 해시 테이블 엔트리(25)의 어느 하나가 발견되지 않았는지를 나타내기 위해 리턴될 수도 있다.

Show_associated_records(cache_id, object_id)(470): cache_id에 의해 식별되는 캐시(2)내에서 object_id에 의해 식별되는 오브젝트(6)가 의존하는 모든 레코드들을 위한 record_id들(12)의 리스트를 리턴한다. 이 기능은 cache_id에 의해 식별되는 캐시(2)에서 object_id에 의해 식별되는 오브젝트(6)를 위한 레코드 리스트(11)(도 3)를 리턴함으로써 구현될 수 있다. 상태 변수도 또한 캐시 또는 오브젝트(6)의 어느 하나가 발견되지 않았는지를 나타내기 위해 리턴될 수 있다.

도 5는 캐시 관리자(1) 로직의 일 예를 나타낸다. 도시한 바와 같이, 단계 1010에서 캐시 관리자는 애플리케이션 프로그램으로부터 커맨드(도 4)를 수신한다. 단계 1020에서, 캐시 관리자는, 커맨드(도 4)를 읽고, 그 커맨드에 근거하여, 후술하는 바와 같은, 서로 다른 로직(1100, ...1600)을 발동한다.

도 6은 cache_object(object_id, object, cache_id)(410) 커맨드를 위한 캐시 관리자 로직(1200)의 일 예를 나타낸다. 도시한 바와 같이, 단계 1200에서, 캐시 관리자(1)는 cache_id 파라미터가 유효 캐시(2)를 특정하는지를 결정한다. 그렇지 않으면, 애플리케이션 프로그램으로 리턴되어야 할 상태 변수를 단계 1245에서 적절히 설정한다. 만일 cache_id가 유효 캐시(2)를 특정하면, 캐시(2)가 바람직하게는 잠기어(lock), 복수의 프로세스들이 동시에 캐시를 액세스하는 것을 방지한다. 그 방식은 일관성을 유지한다. 이 기술분야의 숙련자는 다른 잠금 방식(locking scheme)이 하이 레벨의 동시실행을 제공하기 위해 사용될 수 있음을 알 수 있을 것이다. 본 발명은 바람직한 실시예에서 사용된 예 이외에 매우 다양한 종래의 잠금 방식들도 적용할 수 있다.

단계 1205에서, 캐시 관리자(1)는 디렉토리(3)(도 2)를 검사함으로써 오브젝트(6)를 검색한다. 오브젝트(6)의 이전 사본이 있으면, 단계 1215에서, 오브젝트(6)에 대한 OIB(10)를 갱신하고, 오브젝트 저장소(4) 내의 오브젝트(6)의 구 버전을 새로운 버전으로 대체하고, 상태 변수를 적절히 설정한다. 만일 단계 1205에서 오브젝트(6)의 이전 사본이 발견되지 않으면, 단계 1210에서 오브젝트(6)에 대한 새로운 OIB(10)를 생성하고, 초기화하여, 디렉토리(3)에 저장한다. 캐시 관리자(1)는 또한 오브젝트 저장소(4)내에 오브젝트(6)를 저장하고 상태 변수를 적절히 설정한다.

단계1230에서, 캐시는 다른 프로세스들이 그것을 갱신하도록 하기 위해서 잠금해제된다. 단계 1240에서, 커맨드의 결과를 나타내는 상태 변수가 애플리케이션 프로그램으로 리턴된다. 그 후 프로세싱은 단계 1010으로 리턴된다(도 5).

도 7은 Lookup_object(object_id, cache_id)(415) 커맨드를 위한 로직의 일 예를 나타낸다. 도시한 바와 같이, 단계 1600에서, 캐시 관리자(1)는 cache_id 파라미터가 유효 캐시(2)를 특정하는지를 결정한다. 그렇지 않다면, 단계 1640에서 상태 변수가 적절히 설정되어 단계 1680에서 애플리케이션 프로그램으로 리턴된다. 만일 cache_id가 유효 캐시를 특정하면, 단계 1610에서 캐시(2)가 잠긴다.

단계 1620에서, 캐시 관리자(1)는 디렉토리(3)(도 2)를 검사함으로써 object_id 파라미터에 상응하는 오브젝트(6)를 검색한다. 만일 오브젝트(6)가 발견되지 않으면, 캐시(2)는 단계 1650에서 잠금해제되고; 상태 변수가 단계 1670에서 설정되어 단계 1680에서 애플리케이션 프로그램으로 리턴된다. 만일 단계 1620에서 오브젝트(6)가 발견되면, 캐시(2)는 단계 1630에서 잠금해제되고; 오브젝트(6)는 단계 1660에서 애플리케이션 프로그램으로 리턴된다.

도 8은 Delete_object(object_id, cache_id)(420) 커맨드에 대한 로직의 일 예를 나타낸다. 도시한 바와 같이, 단계 1100에서, 캐시 관리자(1)는 cache_id 파라미터에 상응하는 캐시(2)가 유효한지를 결정한다. 만일 유효하지 않으면, 단계 1103에서 상태 변수가 적절히 설정되고 단계 1150에서 상태 변수가 애플리케이션 프로그램으로 리턴된다.

만일 단계 1100에서 cache_id가 유효한 캐시(2)를 특정하면, 그 캐시는 단계 1105에서 잠긴다. 단계 1107에서, 캐시 관리자(1)는 디렉토리(3)(도 2)를 검사함으로써 object_id 파라미터에 상응하는 오브젝트(6)를 검색한다. 만일 오브젝트(6)가 발견되지 않으면, 캐시는 단계 1108에서 잠금해제되고, 상태 변수는 단계 1109에서 설정되며 단계 1150에서 상태 변수가 애플리케이션 프로그램으로 리턴된다. 만일 단계 1107에서 오브젝트(6)가 발견되면, 단계 1110에서 캐시 관리자(1)는 오브젝트들의 관계 레코드 리스트(11)(도 3)를 삭제하고 상응하는 오브젝트들의 리스트들(8)(도 2)을 갱신한다. 캐시관리자(1)는 오브젝트(6)에 상응하는 레코드 리스트(11)(도 3)의 각 레코드 ID(12)를 스캔한다. 레코드 리스트(11) 상의 각각의 레코드 ID(12)는 상응하는 오브젝트 리스트(8)(도 2)를 가짐을 주목하여야 한다. 삭제된 오브젝트(6)에 상응하는 object_id(들)(9)에 대한 포인터들이 그러한 오브젝트 리스트들(8) 모두로부터 제거된다. 만일 이에 의해 임의의 오브젝트 리스트(8)가 비워지게 되면, 상응하는 해시 테이블 엔트리(25)도 또한 삭제된다. 레코드 리스트(11)의 각 콤포넌트가 검사된 후, 삭제될 수 있다.

단계 1120에서, 오브젝트(6)가 오브젝트 저장소(4)로부터 삭제된다. 단계 1130에서, 상응하는 OIB(10)가 삭제된다. 단계 1120은 단계 1110 및 단계 1130과 동시에 또는 그 전에 수행될 수 있음을 주목하여야 한다. 단계 1140에서, 캐시는 잠금해제되고, 단계 1150에서 상태 변수는 애플리케이션 프로그램으로 리턴된다.

도 9는 Add_dependency(object_id, cache_id, record_id)(430) 커맨드를 위한 로직의 일 예를 나타낸다. 도시한 바와 같이, 단계 1300에서, 캐시 관리자는 cache_id 파라미터가 유효한 캐시(2)를 특정하는지를 결정한다. 만일 그렇지 않다면, 상태 변수는 단계 1302에서 적절히 설정되어 단계 1360에서 애플리케이션 프로그램으로 리턴된다.

만일 단계 1300에서 cache_id가 유효 캐시를 특정한다고 결정되면, 캐시(2)는 단계 1305에서 잠긴다. 단계 1310에서, 캐시 관리자(1)는 디렉토리(3)(도 2)를 검사함으로써 object_id에 상응하는 오브젝트(6)를 검색한다. 만일 단계 1310에서, 오브젝트(6)가 발견되지 않으면, 캐시(2)는 단계 1315에서 잠금해제되고 상태 변수는 단계 1317에서 설정되며, 적절한 상태 변수가 단계 1360에서 애플리케이션 프로그램으로 리턴된다. 만일 단계 1310에서, 오브젝트(6)가 발견되면, 캐시 관리자(1)는 오브젝트(6)와 record_id에 의해 식별되는 레코드간에 연관(즉, 의존성 정보)이 이미 존재하는지를 알아보기 위해 단계 1320에서 레코드 리스트(11)(도 3)를 검사한다. 한편, 만일 record_id에 상응하는 레코드가 해시 테이블 엔트리(25)를 가지고 있는지가 결정될 수 있으며, 만일 그렇다면, 오브젝트 리스트(8) 상에서 object_id(9)를 탐색한다. 단계 1320에서, 오브젝트에 대한 의존성이 존재하면, 캐시(2)는 단계 1325에서 잠금해제되고; 상태 변수는 단계 1327에서 적절히 설정되며; 적절한 상태 변수는 단계 1360에서 애플리케이션 프로그램으로 리턴된다. 단계 1320에서 오브젝트에 대한 의존성이 발견되지 않으면, 단계 1330에서 object_id(9)가 레코드를 위한 오브젝트 리스트(8)에 추가된다. 필요하다면 새로운 해시 테이블 엔트리(25)와 오브젝트 리스트(8)가 레코드를 위해 생성된다. 단계 1340에서, record_id(12)가 오브젝트(6)를 위한 레코드 리스트(11)(도 3)에 추가된다. 단계 1340은 단계 1330과 동시에 또는 그 전에 실행될 수 있음을 주목하여야한다. 캐시(2)는 단계 1350에서 잠금해제되고 상태 변수는 단계 1360에서 애플리케이션 프로그램으로 리턴된다.

도 10은 delete_dependency(object_id, cache_id, record_id)(440) 커맨드를 위한 로직의 일 예를 나타낸다. 나타낸 바와 같이, 캐시 관리자(1)는 cache_id 파라미터가 유효한 캐시(2)를 특정하는지를 결정한다. 그렇지 않다면, 단계 1402에서 상태 변수는 적절히 설정되어 단계 1460에서 애플리케이션 프로그램으로 리턴된다.

단계 1400에서, cache_id가 유효 캐시를 특정한다고 결정되면, 단계 1405에서 캐시는 잠긴다. 단계 1410에서, 캐시 관리자(1)는 디렉토리(3)(도 2)를 검사함으로써 object_id에 상응하는 오브젝트(6)를 검색한다. 만일 단계 1410에서 오브젝트(6)가 발견되지 않으면, 캐시(2)는 단계 1412에서 잠금해제되고; 상태 변수는 단계 1415에서 설정되어 단계 1460에서 애플리케이션 프로그램으로 리턴된다. 만일 단계 1410에서 오브젝트(6)가 발견되면, 캐시 관리자(1)는 오브젝트(6)와 record_id에 의해 식별되는 레코드간에 연관(즉 의존성 정보)이 이미 존재하는지를 알아보기 위해 단계 1420에서 레코드 리스트(11)(도 3)를 검사한다. 한편, record_id에 상응하는 레코드가 해시 테이블 엔트리(25)를 가지고 있는지가 결정될 수 있으며, 만일 그렇다면 오브젝트 리스트(8) 상에서 object_id(9)를 검색한다. 만일 단계 1420에서 의존성이 발견되지 않으면, 단계 1422에서 캐시(2)는 잠금해제되고; 상태 변수는 단계 1425에서 적절히 설정되며; 적절한 상태 변수는 단계 1460에서 애플리케이션 프로그램으로 리턴된다. 만일 단계 1420에서 오브젝트에 대한 의존성이 발견되면, 단계 1430에서 object_id(9)가 레코드를 위한 오브젝트 리스트(8)로부터 삭제된다. 만일 이에 의해 오브젝트 리스트가 비워지면, 레코드에 대한 해시 테이블 엔트리(25)가 삭제된다. 단계 1440에서 record_id(12)가 오브젝트(6)를 위한 레코드 리스트(11)(도 3)로부터 제거된다. 단계 1440은 단계 1430과 동시에 또는 그 전에 실행될 수 있음을 주목하여야 한다. 캐시는 단계 1450에서 잠금해제되고 상태 변수는 단계 1460에서 애플리케이션 프로그램으로 리턴된다.

도 11은 Invalidate_record(cache_id, record_id)(450) 커맨드에 대한 로직의 일 예를 나타낸다. 도시한 바와 같이, 단계 1500에서, 캐시관리자(1)는 cache_id 파라미터가 유효한 캐시를 특정하는지를 결정한다. 캐시가 유효하지 않으면, 상태 변수는 단계1502에서 적절히 설정되어 단계 1550에서 애플리케이션 프로그램으로 리턴된다.

만일 단계 1500에서 캐시 관리자(1)가 cache_id 파라미터가 유효한 캐시(2)를 특정한다고 결정하면, 캐시(2)는 단계 1505에서 잠긴다. 단계 1510에서, 캐시 관리자는 레코드가 해시 테이블 엔트리(25)(도 2)를 가지고 있는지를 알아봄으로써, 임의의 오브젝트들(6)의 값들이 record_id와 연관된 레코드에 의존하는지를 결정한다. 만일 레코드를 위한 해시 테이블 엔트리(25)가 발견되면, 캐시는 단계 1515에서 잠금해제되고 상태 변수는 단계 1517에서 설정된다.

만일 단계 1510에서, 레코드를 위한 해시 테이블 엔트리(25)가 발견되면, 캐시 관리자(1)는 단계 1520에서 레코드를 위한 오브젝트 리스트(8)를 스캔한다. 오브젝트리스트(8) 상에서 오브젝트 ID(9)를 갖는 각 오브젝트(6)는 캐시로부터 삭제된다. 각 오브젝트(6)가 삭제되므로, 오브젝트(6)에 대한 모든 참조들이 오브젝트 리스트들(8)로부터 또한 삭제된다. 그러한 참조들은 삭제된 오브젝트(6)를 위한 레코드 리스트(11)(도 3)를 주사(traverse)함으로써 발견될 수 있다. 만일 임의의 그러한 참조의 삭제로 인해 오브젝트 리스트가 비워지면, 상응하는 해시 테이블 엔트리가 삭제된다. (record_id 파라미터에 상응하는) record_id(12)에 연관된 오브젝트 리스트(8)의 각 요소가 검사된 후, 그 요소가 삭제될 수 있다. 단계 1530에서, 레코드를 위한 해시 테이블 엔트리(25)가 삭제된다. 단계 1540에서 캐시가 잠금해제되고 단계 1550에서 상태 변수가 애플리케이션 프로그램으로 리턴된다.

이 기술분야의 숙련자에 의해 구현될 수 있는 Invalidate_record 기능의 단순한 확장은 그들을 무효화하는 대신에 record_id 파라미터에 의존하는 하나 이상의 오브젝트들을 갱신하는 것이다.

단계 1099는 캐시관리자가 처리하는 다른 커맨드들을 나타낸다.

이 기술분야의 숙련자들은 본 발명의 범주 및 사상 내에서 많은 확장 및 변형들이 있음을 알 수 있을 것이다. 예를 들어, 한 변형예에서는 캐시 관리자로 하여금 오브젝트(6)가 캐시되기 전 및 오브젝트(6)가 캐시로부터 제거된 후에 오브젝트(6)를 위한 OIB(10)(도 2)를 미리 보관(preserve) 및 갱신하도록 하는 것이다. 이러한 방식을 사용하여, 오브젝트(6)가 캐시로부터 제거될 때, 오브젝트(6)를 위한 레코드 리스트(11)를 삭제하고 모든 오브젝트 리스트들(8)로부터 오브젝트(6)를 제거할 필요가 없게 될 것이다. 그 방식에서, 의존성 정보는 오브젝트(6)가 캐시 내에 없는 동안 보관되며 갱신될 수도 있다.

다른 변형예에서는, 캐시 관리자(1)로 하여금 임의의 오브젝트들을 오브젝트 리스트(8)에 추가하기 전 및 오브젝트 리스트(8)가 비워진 후, 즉 캐시 관리자가 레코드에 대한 임의의 의존성을 인식하기 전 및 캐시 관리자가 인식하는 레코드에 대한 모든 의존성들이 낡은 후, 레코드를 위한 해시 테이블 엔트리(25)를 유지하고 갱신하도록 할 것이다. 이는 레코드 ID들(12) 및 오브젝트 리스트들(8) 외에 다른 정보를 해시 테이블 엔트리(25)가 포함하면 특히 유익할 것이다.

다른 실시예

도 12a는 본 발명의 특징들을 갖는 시스템의 다른 예를 나타낸다. 이전의 실시예뿐만 아니라 이 실시예에서, 본 발명은 종래의 클라이언트-서버 환경에서의 서버 애플리케이션들의 성능을 향상시키기 위해 사용될 수 있다. 이 기술분야의 숙련자는 클라이언트-서버 기반이 아닌 다른 애플리케이션들에 대해서도 여전히 본 발명을 용이하게 채택할 수 있을 것이다. 도시된 바와 같이, 클라이언트-서버 구조에서 클라이언트(90)는 네트워크(95)를 통해서 서버(100)와 통신한다. 서버(100)는 하나이상의 캐시들(2')을 유지한다. 종래와 마찬가지로, 서버(100)는 클라이언트(90) 요구들을 충족시키기 위한 CPU 시간을 줄이고 성능을 향상시키기 위해서 캐시들(2')을 사용한다. 비록 도 12a는 단일 서버에 연관된 캐시들(2')을 나타내고 있으나, 캐시들(2')은 복수의 서버들에 걸쳐서도 또한 유지될 수 있다.

서버(100) 상에서 실행되는 애플리케이션은 오브젝트들을 생성한 후 하나 이상의 캐시들(2') 상에 그들 오브젝트를 저장한다. 시스템은 또한 데이터베이스(99)내의 하부 데이터의 소스 및 캐시(2')가 지리적으로 떨어져 있도록 구성될 수 있다. 이 실시예에서, 오브젝트는 하나 이상의 캐시들(2') 내에 저장될 수 있는 데이터이다. 오브젝트들은 데이터베이스(99) 상에 저장된 하부 데이터로부터 구축될 수 있다. 하부 데이터는 하나 이상의 오브젝트들의 값에 영향을 미칠 수도 있는 시스템 내의 모든 데이터를 포함한다. 하부 데이터는 시스템 내의 모든 오브젝트들의 슈퍼세트이다.

본 발명에 따르면, 오브젝트 관리자(120)는 바람직하게는 서버(100)(또는 클라이언트(90))와 같은 컴퓨터 상에서의 실행을 위한 컴퓨터 판독가능 매체에 유형적으로 구체화된 컴퓨터 실행가능 코드("프로그램")로서 구체화될 수 있다. 오브젝트 관리자(20)는 하부 데이터에 대한 변경이 캐시들(2') 내의 오브젝트들의 값들에 어떻게 영향을 미치는지를 결정하는 것을 돕는다. 비록 도 12a가 단일 서버 상에 상주하는 오브젝트 관리자를 나타내고 있으나, 복수의 서버들에 걸쳐서도 또한 분산될 수 있다. 오브젝트 관리자(120)는 바람직하게는 하나 이상의 캐시들(2')을 위한 저장 장치를 관리하는 장기 실행 프로세스(long running process)이다. '캐시' 라는 용어는 매우 일반적이며, 종래의 의미에서의 캐시들 외에 임의의 애플리케이션(예를 들어, 클라이언트(90) 애플리케이션)을 포함할 수 있다. 이 기술분야의 숙련자는 다음의 하나인 오브젝트 관리자를 위해 본 발명을 용이하게 채택할 수 있을 것이다:

1. 시간적으로 전혀 중복되지 않는, 복수의 개별 프로세스들; 및

2. 일부가 시간적으로 중복될 수도 있는, 복수의 개별 프로세스들. 이는 시스템의 스루풋을 개선하기 위해 디자인된 복수의 동시실행 오브젝트 관리자들을 포함한다.

도 12b는 본 발명의 특징들을 갖는 오브젝트 의존성 그래프(121)의 일 예를 나타낸다. 오브젝트 의존성 그래프(121)(G로 간략화됨)는 그래프 오브젝트들(gobj1, ..., gobjn) 간의 데이터 의존성들을 나타낸다. 여기서, gobj1, ..., gobj7은 서로 다른 그래프 오브젝트들을 나타내고 그래프 내의 엣지들(e)은 데이터 의존성들을 나타낸다. 예를 들어, gobj1에서 gobj5로의 엣지는, 만일 gobj1이 변화하면, gobj5도 또한 변화함을 나타낸다. 엣지의 웨이트(w)는, 엣지의소스인 오브젝트에 대한 변경이, 엣지의 목표인 오브젝트에 얼마나 많은 영향을 미치는지를 나타낸 것이다. 예를 들어, gobj1에 대한 변경은 gobj2에 대한 변경보다 gobj5에서 보다 중요한 변경을 내포할 것이다. 이는 gobj1에서 gobj5로의 엣지의 웨이트(w)가 gobj2에서 gobj5로의 엣지의 웨이트(w)의 5배이기 때문이다.

오브젝트 관리자(120)는 오브젝트 의존성 그래프들을 나타내는 하부 데이터 구조들을 유지할 책임이 있다(도 12a∼도 12c 및 도 16 참조). 애플리케이션 프로그램들은 API들의 세트를 통해서 오브젝트 관리자와 오브젝트 의존성 그래프들의 구조를 통신한다(도 18a 참조). 애플리케이션은 또한 변화한 하부 데이터를 오브젝트 관리자에게 통지하기 위하여 API들을 사용한다. 오브젝트 관리자(120)가 하부 데이터에 대한 변경을 통지 받을 때, 어느 다른 오브젝트들이 변화하였는지를 결정하고 캐시들(2')로 변경들을 통지한다. 오브젝트 의존성 그래프에서 다음 엣지들에 의해 어느 다른 오브젝트들이 변화하였는지를 결정한다.

예를 들어, 오브젝트 관리자(120)가 gobj1이 변화하였다고 말한다고 가정하자. 오브젝트 의존성 그래프(121)에서 gobj1로부터의 엣지들을 따름으로써, gobj5 및 gobj7 모두가 또한 변화한다. 다른 예로서, 오브젝트 관리자가 gobj7이 변화하였다고 한다고 가정하자. 오브젝트 의존성 그래프에서 gobj7이 소스인 엣지들이 없으므로, 오브젝트 관리자는 다른 오브젝트들은 전혀 영향을 받지 않는다고 결론을 맺는다.

도 12c는 본 발명의 특징들을 갖는 오브젝트 관리자(120)의 일 예를 나타낸다. 도시한 바와 같이, 오브젝트 관리자(120)는 몇 개의 저장 영역들을 포함한다:

1. 복수의 의존성 정보 블록(DIB들)(128)에 의해 구현되는 오브젝트 의존성 그래프(G)(121')(도 12d 참조). 이 기술분야의 숙련자들은 다양한 데이터 구조들을 사용하여 DIB들이 저장될 수 있음을 알 수 있을 것이다. 바람직하게는, DIB들이 object_id들(160)에 의해 색인되는 종래의 해시 테이블들이 사용된다. 해시 테이블들은, 예를 들어, Aho, Hopcroft, Ullman, Addison-Wesley, 1974년의 "The Design and Analysis of Computer Algorithms(컴퓨터 알고리즘의 디자인 및 분석)"에 서술되어 있다.

2. 복수의 레코드 트리(MRT)(122)(도 27∼도 28 참조)

3. 단일 레코드 트리(SRT)(123)(도 27∼도 28 참조)

4. 다음에 제한되지는 않으나 이를 포함하는 보조 상태 정보(124):

a. num_updates(125): 오브젝트 관리자가 그래프를 통해 전파하였던 갱신들의 번호를 추적하기 위해 오브젝트 관리자에 의해 유지되는, 카운터 num_updates(125).

b. 일관성 스택(128.5): 갱신동안 일관성을 유지하는데 사용됨.

c. 관계 정보(129)(도 27∼도 28 참조)

5. 프로그램 로직(126).

도 13은 각 캐시(127)에 의해 유지되는 저장 영역의 일 예를 나타낸다. 각 캐시는 그것을 식별하는 cache_id(135) 필드를 갖는다. 3개의 주요 저장 영역들이 있다:

1. 디렉토리(130): 오브젝트들에 관한 정보를 유지한다. 디렉토리(130)는 복수의 오브젝트 정보 블록들(OIB들)(10')을 포함한다. 오브젝트에 관한 정보는 오브젝트가 캐시를 떠난 후에 OIB(10')(도 14) 내에 유지될 수도 있다. 이 기술분야의 숙련자들은 다양한 데이터 구조들을 사용하여 OIB들이 저장될 수 있음을 알 수 있을 것이다. 바람직하게는, OIB들이 object_id들(160)에 의해 색인되는 종래의 해시 테이블이 사용된다.

2. 오브젝트 저장소(132): 캐시 내에 포함되는 오브젝트들이 저장되는 곳.

3. 보조 상태 정보(124): 다른 상태 정보, 예를 들어 cache_id(135)를 포함한다.

도 14는 OIB(10')의 일 예를 나타낸다. OIB는 바람직하게는 다음을 포함한다.

object_id(160): 다음 논의를 위해 오브젝트가 object_id(o1)를 갖는다고 가정한다;

version_num(141): 오브젝트 관리자로 하여금 다른 버전들의 동일 오브젝트를 고유하게 식별하도록 한다;

timestamp(142): 오브젝트가 얼마나 최근에 산출되었는지를 나타내는 번호;

actual_weight(143): 캐시된 버전 o1이 현행 버전 o2와 일관성을 갖도록 하는 그래프 오브젝트 o2로부터 o1로의 모든 엣지들의 웨이트들의 합; 및

dep_list(144): 오브젝트 o1에 대한 의존성들을 나타내는 리스트.

도 15는 dep_list(144) 요소의 일 예를 나타낸다. 도시한 바와 같이, 각 리스트는 바람직하게는 다음을 포함한다:

object_id(160): o1에 대한 의존성 엣지를 갖는 그래프 오브젝트 o2, 즉 o2가 소스이고 o1이 목표임을 나타낸다;

weight_act(152): o2의 최신 버전이 o1의 캐시된 버전과 얼마큼 일치되는지를 나타내는 번호. 바람직한 실시예는 의존성 정보 블록(DIB)(128)(도 16)에서 상응하는 엣지를 위해 0(전체 불일치) 또는 웨이트 165(도 16)(전체 일치)의 값들을 사용한다. 단순한 확장에 의해 불일치의 정도를 나타내는 이들 2개의 극값들 사이의 값들이 허용될 것이다; 및

version_num(153): o1의 캐시된 버전과 일치하는 o2의 version_num.

도 16은 도 12의 의존성 정보 블록(DIB)(128)의 일 예를 나타낸다. 도시된 바와 같이, DIB(128)는 바람직하게는 다음 필드들을 포함한다:

object_id(160): 그래프 오브젝트를 식별하기 위해 애플리케이션 프로그램에 의해 사용됨. 다음 논의를 위해 그래프 오브젝트는 object_id o1을 갖는다고 가정한다;

version_num(161): 그래프 오브젝트의 현행 버전을 나타내는 버전 번호;

timestamp(162) : 그래프 오브젝트의 현행 버전을 나타내는 타임스탬프;

(오브젝트들인 그래프 오브젝트들을 위한) storage_list(163): 오브젝트를 포함하는 모든 캐시들을 위한 cache_id들의 리스트;

incoming_dep(164): o1로의 의존성 엣지를 갖는 모든 그래프 오브젝트들 o2에 대한 (object_id(160), weight(165)) 쌍들의 리스트. 웨이트(165)는 의존성의 중요도를 나타낸다. 예를 들어, 보다 높은 번호들은 더 중요한 의존성들을 나타낼 수 있다;

outgoing_dep(166): o1로부터 유래하는 의존성 엣지가 존재하는 모든 object_id들의 리스트;

sum_weight(167): o1로 들어가는 모든 의존성 엣지들의 웨이트들의 합;

(오브젝트들인 그래프 오브젝트들을 위한) threshold_weight(168): 오브젝트가 매우 낡은 것이라고 간주되어야만 할 때를 나타내는 번호. OIB(10')(도 14)에서 actual_weight(143) 필드가 오브젝트를 위한 threshold_weight(168) 이하로 떨어질 때, 오브젝트는 매우 낡았다고 간주되어야 하며 캐시로부터 무효화되거나 또는 갱신되어야 한다.

(오브젝트들인 그래프 오브젝트들을 위한) consistency_list(169): 현행 오브젝트들과 일관성이 유지되어야만 하는 다른 오브젝트들에 상응하는 object_id들(160)의 리스트. 바람직하게는, 일관성은 동일 캐시 내의 오브젝트들간에만 집행된다. 단순한 확장으로 복수의 캐시들간에 오브젝트들의 일관성이 집행될 수도 있을 것이다. 다른 단순한 확장으로, 리스트(169) 상의 모든 오브젝트들이, object_id가 캐시 내부/외부에 있을 때마다 캐시의 내부/외부에 있어야 함이 요구될 수도 있을 것이다.

(오브젝트들인 그래프 오브젝트들을 위한) latest_object(1601): 오브젝트의 최신 버전의 대한 포인터로, 오브젝트 관리자가 그러한 사본을 인식하지 못하면 0(null)임. 이 필드는 매번 그의 값을 재산출하지 않고 복수의 캐시들 내에서 오브젝트가 갱신되도록 한다.

relational_string(1602): 그래프 오브젝트가 관계 오브젝트가 아니면 0(null)임. 그렇지 않은 경우, 이것의 형태는: SRO들을 위한 관계_이름(25, 30)과 MRO들을 위한 관계_이름(>=50). 다음은 relational_string(1602)이 0이 아닌 경우에만 관련된다.

multiple_records(1603): 그래프 오브젝트가 복수의 레코드 오브젝트(MRO)이면 참, 단일 레코드 오브젝트(SRO)이면 거짓;

다음은 multiple_records(1603)이 참인 경우에만 관련된다:

mro_dep_weight(1604): 또 다른 관계 오브젝트로부터 o1로의 암시적 의존성에 할당된 웨이트; 및

mro_threshold_increment(1605): o1에 대한 각 암시적 의존성을 위해, 증가되어야만 하는 임계_웨이트의 양.

도 12를 다시 참조하면, 오브젝트 관리자는 바람직하게는 오브젝트 관리자가 그래프를 통해 전파하는 갱신들의 수를 추적하는 카운터 번호_갱신들(125)(초기값은 0)을 또한 유지한다. 오브젝트 관리자는 또한 캐시들 내의 오브젝트들간에 일관성을 유지하는데 사용되는 일관성 스택(128.5)(도 12c)이라 불리는 데이터 구조(초기에는 비워져 있음)를 유지한다.

애플리케이션 프로그램(97)은 바람직하게는 API 기능의 세트를 통해서 오브젝트 관리자와 통신한다. 도 17은 본 발명에 따른 몇 개의 API들의 예들을 포함한다. 이 기술분야의 숙련자은 다른 API들이 본 발명의 관점에서 단순한 확장으로 구현될 수 있음을 알 수 있을 것이다.

도 18은 서로 다른 API 기능들을 취급하기 위한 오브젝트 관리자(120) 로직의 일 예를 나타낸다. 이 기능들을 나중에 상세히 설명하기로 한다. 개관하면, 오브젝트 의존성 그래프(G)(121)에서의 노드들은 오브젝트 관리자에 대한 API: create_node(obj_id, initial_version_num, thresh_weight)(181)를 통해 생성될 수 있다. 그래프 내에 현존 노드들간의 의존성들은 API 호출: add_dependency(source_object_id, target_object_id, dep_weight)(182)을 통해 생성될 수 있다. 오브젝트 "object_id"에 상응하는, consistency_list(169)는 API 호출: define_consistency_list(obj_id, list_of_objects)(183)을 통해 설정될 수 있다. API: delete_node(obj_id)(184)를 통해 G로부터 노드들이 삭제될 수 있다. API cache_latest_version(obj_id, cache)(185)는 캐시에 오브젝트의 최신 버전을 추가한다. API copy_object(obj_id, to_cache_id, from_cache_id)(186)는 하나의 캐시에서 또 다른 캐시로 오브젝트의 버전의 복사를 시도한다. 오브젝트들은 API 호출: delete_object(obj_id, cache)(187)을 통해 캐시로부터 삭제된다.

하부 데이터의 값을 변경하는 애플리케이션 프로그램은 오브젝트 관리자에게 통지하여야 한다. 이를 달성하기 위한 2개의 API 호출은: object_id 파라미터가 그래프 오브젝트를 식별하는 object_has_changed(obj_id)(188); 및 list_of_objects 파라미터가 그래프 오브젝트들(에 대한 포인터들)의 리스트를 포함하는 objects_have_changed(list_of_objects)(189)이다.

SRO에 상응하는 노드는 API create_sro_node(obj_id, initial_version_num, thres_weight, relation_name, list_of_attribute_value) (190) 호출을 통해 생성된다.

MRO들은 API: create_mro_node(obj_id, initial_version_num, thresh_weight, relation_name, list_of_attribute_conditions, rel_default_weight, rel_default_threshold)(191)를 통해 생성된다.

API compare_objects (obj_id, cache_id1, cache_id2)(192)은 cache_id1과 cache_id2의 버전들이 얼마큼 유사한지를 결정하는데 사용될 수 있다. API update_cache(cache)(193)는 캐시 내의 모든 항목들이 현행되는 것임을 확인한다. API define_relation (relation_name, list_of_attributes)(194)는 오브젝트 관리자에 대한 관계들을 식별한다. 하나 이상의 레코드들이 변할 때, 이것이 API들 record_has_changed (relation_name, list_of_attribute_values)(195)와 records_have_changed (relation_name, list_of_attribute_conditions)(196)를 통해서 오브젝트 관리자에게 통지될 수 있다.

오브젝트 의존성 그래프(G)(121)에서의 노드들은 오브젝트 관리자에 대한 API 호출: create_node(obj_id, initial_version_num, thresh_weight)(181)를 통해 생성된다. 이 기술분야의 숙련자들은 본 발명의 사상 및 범주 내에서 단순한 방식으로 많은 추가적인 API들이 구현될 수 있음을 알 수 있다. 예를 들어, API들은 노드가 생성된 후 object_id(160), version_num(161) 및 threshold_weight(168)를 변형하기 위해 추가될 수 있다.

그래프 내에 현존하는 노드들간의 의존성들은 API 호출: add_dependency(source_object_id, target_object_id, dep_weight)(182)를 통해서 생성된다.

이 기술분야의 숙련자들은 본 발명의 사상 및 범주 내에서 단순한 방식으로 많은 추가적인 API들이 구현될 수 있음을 알 수 있다. 예를 들어, API들은 또한 의존성들을 삭제하고 의존성 웨이트들을 변형하기 위해서 추가될 수도 있다.

"object_id"에 상응하는 consistency_list(169)는 API 호출: define_consistency_list(obj_id, list_of_objects)(183)를 통해 설정된다. obj_id에 대한 일관성 리스트는 바람직하게는 멤버로서 obj_id를 포함하도록 허여되지 않는다. API들은 이것이 일어나는 것을 방지한다.

consistency_lists(169)을 생성한 후 이를 변형하기 위하여 본 발명의 사상 및 범주 내에서 API들이 간단하게 추가될 수 있다.

오브젝트가 캐시된 후, 오브젝트를 위한 의존성 정보 블록(DIB)(128)(도 16)에 대한 변경들은 하나 이상의 캐시들(127)에 대한 갱신을 요구할 수도 있다. 이들은 단순하다. 새로운 그래프 오브젝트 o2로부터 캐시된 오브젝트 o1로 새로운 의존성이 생긴 경우, 오브젝트 관리자가 o2가 생성되었을 때를 모르거나, 또는 o2에 대한 DIB timestamp(162) > o1에 대한 OIB timestamp이면, 새로운 의존성은 낡은 것이다. 노드들은 API, delete_node(obj_id)(184)를 통해 G로부터 삭제될 수 있다.

오브젝트들은 API들: cache_latest_version(obj_id, cache)(185); 및 copy_object(obj_id, to_cache_id, from_cache_id)(186)를 통해서 캐시들에 명시적으로 추가될 수 있다. 이들 API들은, 오브젝트에 대해 OIB들(135)이 아직 존재하지 않으면 캐시 디렉토리 내에 새로운 OIB들(135)을 생성한다.

도 19는 API, cache_latest_version(obj_id, cache)(185)의 일 예를 나타낸다. 도시한 바와 같이, 단계 2030에서, object_id 및 캐시 파라미터는 현행하는 오브젝트들 및 캐시들을 각각 특정함이 실증된다. 만일 그렇다면, 프로세싱은 단계 2040으로 진행한다. 그렇지 않다면, 적절한 상태 메시지가 리턴되고 프로세싱은 단계 2010으로 진행한다. 단계 2040에서, obj_id의 최신 버전이 캐시 내에 있는지가 결정된다. 만일 그렇다면, 프로세싱은 단계 2010에서 계속된다. 만일 그렇지 않다면, 단계 2050에서 의존성 정보 블록(DIB)(128)(도 16) 내의 latest_object 필드(1601)로부터 obj_id의 최신 버전을 얻으려는 시도가 이루어진다. 단계 2050에서, 이 필드가 0이면, obj_id의 최신 값이 산출되고 (그리고 될 수 있는 한 DIB의 최신_오브젝트 필드(1601)를 통해 그 값을 액세스 가능하게 하고), 의존성 정보 블록(DIB)(128)(도 16) 내에서의 version_num 필드(161)가 갱신된다. 단계 2050에서, obj_id의 새로운 버전이 전체적으로 재산출하거나 또는 단지 그의 일부만이 재산출하고 새로운 부분들을 현존하는 버전들의 부분들과 합체한다. 후자의 방법이 종종 전자의 방법보다 더욱 효율적이다.

obj_id에 대한 OIB(10')는, 아직 존재하지 않으면, 캐시를 위한 디렉토리(130)에서 생성된다. 만일 캐시가 이전에 포함하고 있는 obj_id의 버전이 없다면, 캐시가 obj_id의 storage_list(163)에 추가된다. OIB(10')(도 14)의 version_num(141) 및 timestamp(142) 필드들은 의존성 정보 블록(DIB)(128)(도 16)의 version_num(161) 및 timestamp(162) 필드들에 설정된다. OIB(10')(도 14)의 actual_weight 필드(143)는 DIB의 sum_weight 필드(167)에 설정된다. OIB(10')(도 14)의 dep_list(144)에 속하는 트리플렛(o2, weight_act, version_num) 각각에 대해, weight_act(152)가 DIB의 incoming_dep(164) 상에 상응하는 엣지를 위한 웨이트(165)에 설정된다. version_num(153)은 o2를 위한 DIB 내에 포함된 version_num(161) 필드로 설정된다. 단계 2060에서, 일관성이 지켜짐이 확인된다. 이 기능은, obj2를 위한 OIB(10')에서의 timestamp(142)가 obj_id를 위한 DIB(128)에서의 timestamp(162) 이전일 때마다 obj_id를 위한 consistency_list(169) 상에 현행하지 않은 모든 오브젝트들 obj2가 갱신되거나 또는 무효화됨을 반복적으로 확인한다. 만일 임의의 그러한 오브젝트들 obj2가 이 프로세서에서 갱신되면, 유사한 절차가 상기 obj2 각각을 위한 consistency_list들(169)에 반복적으로 적용된다. 단계 2050 및 단계 2060의 순서는 이 실시예와 똑같이 할 필요가 있는 것은 아니다.

도 20은 API copy_object(obj_id, to_cache_id, from_cache_id)(186)의 일 예를 나타낸다. 도시한 바와 같이, 단계 2100에서 obj_id, to_cache_id 및 from_cache_id 파라미터들은 모두 오브젝트 관리자에 의해 인식됨이 확인된다. 만일 그렇다면, 단계 2110에서 from_cache_id가 obj_id의 사본을 가지고 있는지를 결정한다. 만일 그렇지 않다면, 아무것도 수행되지 않고 단계 2010으로 프로세싱이 진행한다. 상태 변수는 이를( 및 또한 다른 경우들도) 위해 적절히 설정되고 무엇이 일어났는지를 나타내기 위해 애플리케이션 프로그램으로 리턴된다. 그렇지 않으면, 프로세싱은 단계 2120으로 계속되어, to_cache_id 및 from_cache_id가 obj_id의 동일한 버전들을 포함하는지를 결정한다. 만일 그렇다면, 복사 할 필요가 없으며, 프로세싱은 단계 2010으로 계속된다. 그렇지 않으면, 단계 2130은 from_cache_id가 object_id의 최신 버전을 포함하는지를 결정한다. 만일 그렇다면, 단계 2140에서, 오브젝트는 to_cache_id의 오브젝트 저장(132) 영역으로 복사되고 캐시 디렉토리(130)가 갱신된다. 만일 obj_id를 위한 OIB(10')가 아직 존재하지 않으면 to_cache_id를 위한 디렉토리(130)내에 obj_id를 위한 OIB(10')가 생성된다. 만일 to_cache_id가 이전에 포함하고 있는 obj_id의 버전이 없다면, to_cache_id가 obj_id의 storage_list(163)에 추가된다. 단계 2170에서, obj_id의 DIB timestamp(162) 이전에 OIB timestamp(142)를 가진 일관성 리스트들(169)상에 현행하지 않는 모든 오브젝트들이 갱신되거나 또는 무효화됨을 확인함으로써 일관성이 유지된다. 그렇지 않으면, 단계 2130의 결과가 부정적이면, 단계 2150에서 오브젝트는 다음의 경우가 아니면 복수가 허여되지 않을 것이다: (1) to_cache_id 내에 저장된 현행하지 않는 버전들을 위한 obj_id를 위한 일관성 리스트(169) 상의 모든 오브젝트들이 from_cache_id내에 obj_id 버전을 위한 timestamp(142)와 동일한 timestamp(142)를 가지며; 또 (2) to_cache_id 내에 저장된 현행 버전들을 위한 obj_id를 위한 일관성 리스트(169) 상의 모든 오브젝트들이 from_cache_id 내에 obj_id 버전을 위한 timestamp(142)와 동일하거나 또는 빠른 timestamp(142)를 갖는 경우. 만일 이들 조건들이 충족되면, 단계 2160에서 obj_id는 from_cache_id로부터 to_cache_id로 복사된다.

아직 존재하지 않는다면 to_cache_id를 위한 디렉토리(130)내에 obj_id를 위한 OIB(10')가 생성된다. 만일 to_cache_id가 이전에 포함하고 있는 obj_id의 버전이 없다면, to_cache_id가 obj_id의 storage_list(163)에 추가된다.

copy_object 및 cache_latest_version API들의 단순한 확장은, 만일 일관성 리스트 상의 다른 오브젝트들이 또한 갱신될 필요가 있다면 오브젝트가 저장되는 것을 방지할 수 있는 플래그들일 수 있다. 다른 단순한 확장은, 만일 캐시가 object_id의 어떠한 버전도 포함하지 않으면 단지 object_id를 캐시 내에 설치하는 추가 플래그들일 것이다.

또 다른 단순한 확장은 오브젝트의 이전의 모든 버전들을 오브젝트 관리자가 유지하고 있는 시스템일 것이다. 그 때 우리는 캐시에 대한 특별한 (object_id, version_num) 쌍에 의해 식별되는 특정 오브젝트를 추가하기 위한 API들을 갖게 될 수 있다.

오브젝트들은 API 호출: delete_object(obj_id, cache)(187)를 통해 캐시로부터 삭제된다. 이 기술분야의 숙련자는 이 상세한 설명에 따라 이 기능을 구현하는 것이 단순함을 알 수 있을 것이다. 이 API 호출에 의해 수행되는 기능의 일 예는, obj_id에 의해 식별되는 오브젝트를 위한 의존성 정보 블록(DIB)(128)(도 16)의 storage_list 필드(163)로부터 cache를 제거하는 것이다.

하부 데이터의 값을 변경하는 애플리케이션 프로그램은 오브젝트 관리자에게 통지하여야만 한다. 이를 수행하기 위한 2개의 API 호출들은: obj_id 파라미터가 그래프 오브젝트를 식별하는 object_has_changed(obj_id)(188); 및 list_of_objects 파라미터가 그래프 오브젝트들(에 대한 포인터들)의 리스트를 포함하는 objects_have_changed(list_of_objects)(189)이다.

만일 list_of_objects 상의 그래프 오브젝트들이 공통적으로 많은 다른 그래프 오브젝트들에 영향을 미치면, objects_have_changed API는, 리스트 상의 각 그래프 오브젝트마다 한번씩, object_has_changed API를 발동하는 것보다 더욱 효율적일 것이다.

도 21은 API, objects_have_changed(list_of_objects)(189)의 일 예를 나타낸다. 이 기술분야의 숙련자들은 API, 이것이 object_has_changed(obj_id)를 구현하는 것으로 단순화될 수 있음을 알 것이다.

설명의 편의를 위해, list_of_objects의 각 요소는 G에서 유효 노드에 상응하며 list_of_nodes의 어떤 2개의 요소들도 동일한 노드를 언급하지 않는다고 가정하자. 이것이 그 경우가 아닌 상황들을 위해 상세한 설명으로부터의 이 기능을 단순히 채택할 수 있을 것이다. 도시한 바와 같이, 단계 2400에서 counter num_updates(125)(도 12c)를 1씩 증가시킨다. 단계 2402에서, list_of_objects 파라미터에 의해 특정된 그래프 오브젝트들에 상응하는 모든 노드들이 방문되었는지를 결정한다. 만일 그렇다면, 단계 2403에서, 갱신 전파 페이즈(update propagation phase)(도 22 참조)에 이어 단계 2404에서 일관성 체크 페이즈(도 26 참조)가 수행된다. 만일 그렇지 않다면, 단계 2405에서, list_of_objects 상의 그래프 오브젝트에 상응하는 새로운 노드가 방문된다. obj_id를 노드를 위한 object_id(160)로 하자. 오브젝트 관리자는 obj_id를 위한 의존성 정보 블록(DIB)(128)(도 16) 내에 version_num 필드(161)를 1씩 증가시키고 num_updates(125)의 값으로 timestamp 필드(162)를 설정한다. 단계 2406 및 단계 2408은 그의 버전을 갱신하거나 또는 무효화하기 위해 (storage_list(163)로부터 얻은) obj_id를 포함하는 각각의 캐시 c1로 obj_id를 통지하는 루프를 나타낸다. 단계 2406에서, 기능 update_or_invalidate(c1, obj_id)(도 25 참조)가 호출되어 이것이 일어나도록 한다.

이 기술분야의 숙련자들은 그들의 obj_id의 사본들을 갱신 또는 무효화하여야만 하는 캐시들이 어느 것인지를 결정하는 단계 2406에 선택성(selectivity)을 적용하는 것이 단순하다는 것을 알 수 있을 것이다.

도 25는 update_or_invalidate(cacheid, objectid) 로직의 일 예를 나타낸다. 이것은 cacheid 내에 현존하는 objectid의 버전이 갱신되거나 또는 무효화되어야만 할 때마다 호출된다(예를 들어, 도 21의 단계 2406 참조). 도시된 바와 같이, 단계 2407에서 objectid가 cacheid에서 갱신되어야만 하는지를 결정한다. 만일 대답이 '아니오'이면, objectid는 단계 2440에서 캐시로부터 무효화되고 절차는 단계 2441에서 리턴한다. 만일 대답이 '예'이면, 단계 2442에서 objectid를 위한 OIB(10')(도 14)에 다음과 같은 변경들이 일어난다:

1. version_num(141) 및 timestamp(142) 필드들은 의존성 정보 블록(DIB)(128)(도 16)에 포함된 현행 version_num(161) 및 timestamp(162)로 설정된다.

2. actual_weight 필드(143)는 DIB에서 sum_weight 필드(167)로 설정된다.

3. dep_list(144)(도 15)가 갱신된다. 리스트(144)의 각 멤버는 objectid에 의해 식별되는 오브젝트에 대한 의존성을 갖는 그래프 오브젝트 o2에 상응한다. weight_act(152)는, 이들 2개의 양들이 서로 다르면 G에서 동일 엣지에 상응하는 의존성 정보 블록(DIB)(128)(도 16)내의 웨이트(165) 필드로 설정된다. 또한, version_num(153)은 이들 2개의 양들이 다르면 DIB내에 포함된 version_num 필드(161)로 설정된다.

단계 2444에서, 오브젝트 저장 영역(132) 내에 포함된 objectid의 실제 값이 갱신된다. 먼저, 의존성 정보 블록(DIB)(128)(도 16) 내의 latest_object 필드(1601)로부터 objectid의 갱신된 버전을 얻기 위한 시도가 이루어진다. 만일 이것이 성공하면, 단계 2444는 종료한다. 만일 이것이 실패하면(즉, 이 포인터가 무효(nil)이면), 예를 들어 objectid의 새로운 버전을 전체적으로 산출하거나 또는 단지 그의 부분들을 재산출하여 현존하는 버전들로부터의 부분들과 새로운 부분들을 합체함으로써, objectid의 갱신된 버전이 산출된다. 후자의 방법이 종종 전자의 방법보다 더 효율적이다. 어느 한 경우에, 오브젝트 관리자는 그 때 objectid의 최신 버전을 필요로 할 수도 있는 다른 캐시들이 그것을 재산출하는 대신에 단순히 그것을 복사할 수 있도록 하기 위해서 DIB 내의 latest_object 필드(1601)를 갱신하는 옵션을 가진다.

어떤 경우에는, 단계 2444에서 objectid의 실제값은 objectid의 보다 나중 버전, 바람직하게는 실제로 현행되지는 않는 (일반적으로 가장 높은 version_num(141)을 갖는 캐시되어 있는) 용이하게 액세스할 수 있는 최신의 것으로 갱신될 수 있다. 이것은 objectid의 현재 값을 산출하는 것이 지나치게 비용이 높은 경우에 이롭다. 바람직하게는 이 형태의 갱신은 다음의 어느 하나가 참이면 허여되지 않는다:

1. objectid가 objects_have_changed(list_of_objects)로 전해지는 리스트 상의 오브젝트들 중의 하나이거나; 또는

2. objectid의 보다 나중 버전에 대해서, 여전히 actual_weight(143)<threshold_weight(168)인 경우.

단계 2443에서, (object_id(160), cacheid) 쌍들은 cacheid에 의해 식별되는 캐시에 있는 consistency_list(169) 상의 각 오브젝트에 대한 의존성 스택(128.5)에 추가된다. 오브젝트 관리자(120)는 의존성 스택(128.5) 상의 캐시된 모든 항목들이 의존성 체크 페이즈(도 26)에서 일관됨을 확인한다.

의존성 스택은 다음 몇 가지 형식으로 구현될 수 있다: 2개의 가능한 구조들은 리스트들 및 밸런스 트리들이다(참조: Aho, Hopcroft, Ullman) 리스트들은 삽입이 일정 시간이라는 이점을 갖는다. 단점은 항목들의 중복 사본들이 마침내 그들이 될 수 있다는 것이다. 트리들은 중복 항목들이 저장될 필요가 없다는 이점을 갖는다. 단점은, n이 의존성 스택상의 항목들의 수라고 할 때, 삽입이 O(log(n))이라는 것이다.

단계 2443은 임의적으로 의존성 스택에 오브젝트를 추가하기 전에 선택성을 더 적용할 수도 있다. object_id2를 cacheid에 있는 일관성 리스트(169) 상의 오브젝트라고 하자. 만일 cacheid가 object_id2의 현행 버전을 포함하면, (object_id2, cacheid)은 의존성 스택에 부가될 필요가 없다. 만일 다음 2가지가 모두 참이면 버전은 현행하는 것이다:

1. object_id2에 상응하는 꼭지점은 objects_have_changed (list_of_objects)(189)에 대한 현행 호출을 프로세스함에 있어 이미 방문됨. 이는 단지 object_id2를 위한 의존성 정보 블록(DIB)(128)(도 16) 내의 timestamp 필드(162)가 num_updates(125)와 동등한 경우에만 참임; 그리고

2. object_id2를 위한 OIB(10')(도 14)내의 version_num 필드(141)와 DIB 내의 version_num 필드(161)가 동일함.

만일 단계 2443에서 (1) 및 (2)가 모두 참이라고 결정되면, (object_id2, cacheid)은 의존성 스택에 추가되지 않는다. 만일 (1)이 참이고 (2)가 거짓이면, 단계 2443은 의존성 스택에 (object_id2, cache_id)를 추가할 필요를 제거하려고 object_id2 및 cacheid 상에 update_or_invalidate를 반복해서 호출할 수 있다.

이 기술분야의 숙련자는 이 설명으로부터 단계 2442, 2443 및 2444를 어떤 순서로 또는 병렬로 용이하게 구현할 수 있을 것이다.

도 22는 objects_have_changed (list_of_objects)(189)를 위한 갱신 전파 페이즈의 일 예를 나타낸다. 단계 2403 및 2416에 의해 수행되는 기본 기능은 list_of_objects로부터 액세스 가능한 그래프(G)의 모든 엣지들을 주사(traverse)하는 것이다. 바람직한 테크닉으로는 깊이-우선 검색("dfs")(참조: Aho, Hopcroft, Ullman)에 유사한 것이다. 그러나, 이 기술분야의 숙련자는 그 테크닉을 넓이-우선 검색(breadth-first search)과 같은 다른 그래프 주사 방법으로 작동되도록 용이하게 적응시킬 수 있을 것이다.

도 23은 하부 데이터에 대한 변경들에 응답하여, 깊이 우선 방식으로 오브젝트 의존성 그래프를 통해서 변경들을 전파하는 방법의 일부 예를 나타낸다. 제1 노드(obj1)에서 제2 노드(obj2)로의 엣지만이 주사된다고 가정하자. 단계 2416에서, 노드(obj2)가 이미 방문되었는지를 결정한다. obj2를 위한 timestamp(162)(도 16)=num_updates(125)(도 12)인 경우에만 그 대답이 '예'가 된다.

단계 2416의 결과가 참이면, 프로세싱은 단계 2417에서 계속된다. 이 단계는 obj2의 사본을 그들이 포함하는지를 알아보기 위해 storage_list(163)(도 16) 상의 모든 캐시들이 검사되는 루프의 일부이다. 각 오브젝트는 바람직하게는 object_id 필드 및 version_number 필드를 가짐을 상기하여야 한다. object_id 필드는 애플리케이션 프로그램이 오브젝트(예를 들어, URL)를 식별하는데 사용할 수 있는 것에 상응하며, version_number 필드는 동일한 object_id를 가진 복수의 오브젝트들이 유지되고 고유하게 식별될 수 있도록 한다. 그러한 캐시 cacheid 각각에 대해서, 단계 2420에서 OIB(10')(도 14) 내의 version_num 필드(141)와 의존성 정보 블록(DIB)(128)(도 16) 내의 version_num 필드(161)를 비교함으로써 obj2의 버전이 현행하는 것인지를 결정한다. 만일 단계 2420에서의 결과가 긍정적이면, 단계 2421에서 obj2를 위한 dep_list(144) 상에서, obj1에 상응하는 요소가 obj1을 위한 DIB 내에서 version_num(161)과 같은 version_num(153)을 갖는다.

단계 2420의 결과가 부정적이면, 즉 obj2의 버전이 현행하지 않으면, decrease_weight(cacheid, obj1, obj2)가 호출된다(도 24 참조). 각 엣지는 데이터 의존성의 중요도를 나타내는 웨이트로 알려진 것과 연관된 음수 아닌 번호를 가질 수 있음을 상기하여야 한다. 예를 들어, 높은 번호들은 중요한 의존성들을 나타내며, 낮은 번호들은 덜 중요한 의존성들을 나타낼 수 있다. 오브젝트들은 그들과 연관된 threshold_weight로 알려진 값을 또한 가질 수 있다. 현행하는 인입 데이터 의존성들에 상응하는 웨이트들의 합이 threshold_weight 아래로 떨어질 때마다, 오브젝트는 매우 낡은 것으로 간주된다. 그러한 오브젝트들은 오브젝트들의 최근 버전들을 요구하는 애플리케이션들을 위해서 갱신되거나 또는 무효화되어야만 한다.

단계 2416의 결과가 거짓이면, 단계 2423에서 obj2를 위한 version_num 필드(161)는 증가되고 timestamp 필드(162)는 obj2가 방문하였음을 나타내는 num_updates(125)(도 12)로 설정된다. 단계 2424는 그들이 obj2의 사본을 포함하는지를 알아보기 위해 storage_list(163) 상의 모든 캐시들이 검사되어야 하는 루프의 일부이다. 그러한 캐시 cacheid의 각각에 대해서, 단계 2425에서 decrease_weight (cacheid, obj1, obj2) 기능이 호출된다. 이 루프를 빠져나간 후, 단계 2426에서 dfs 로직(도 23)이 obj2로부터 뻗어 나온 모든 엣지들 상에 반복적으로 호출된다.

도 24는 decrease_weight(cacheid, from_obj, to_obj) 로직의 일 예를 나타낸다. 도시한 바와 같이, 단계 2425에서 to_obj를 위한 actual_weight 필드(143)는 w만큼 감소되며, w는 from_obj에서 to_obj로의 엣지에 상응하는 weight_act 필드(152)이다. 단계 2435에서, actual_weight(143)<threshold_weight (168)인지를 결정하고; 만일 대답이 '예'이면, update_or_invalidate cacheid(cacheid, to_obj) 기능이 호출된다. 만일 대답이 '아니오'이면, 단계 2436에서 from_obj에서 to_obj로의 엣지에 상응하는 weight_act 필드(152)가 0으로 설정된다.

갱신 전파 페이즈 후, 오브젝트 관리자는 consistency_lists(169)가 실제로 일치되는지를 확인하여야만 한다. 이는 도 26에 나타낸 일관성 체크 페이즈에서 행해진다. 도시한 바와 같이, 단계 2404는 의존성 스택(128.5)(도 12c)에서 각 (object_id(160), cache_id(135)) 쌍을 검사하는 루프의 일부이다. 그러한 쌍의 각각에 대해서, 단계 2451에서 version_num 필드(141)를 version_num 필드(161)와 비교함으로써 캐시 cache_id 내의 object_id의 버전이 현행하는지를 결정한다. 만일 대답이 '예'이면, 프로세싱은 단계 2404로 리턴된다. 그렇지 않으면, 오브젝트는 갱신되거나 또는 무효화되어야만 한다. 단계 2455에서 오브젝트가 갱신되어야만 하는지를 결정한다. 만일 대답이 '아니오'이면, 오브젝트는 이미 설명한 단계 2440에서 무효화된다(도 25 참조). 만일 대답이 '예'이면, 최근 값이 단계 2050에서 캐시에 추가되고 새로운 의존성 제한들(constraints)은 단계 2060에서 충족된다. 여기서 단계 2050 및 단계 2060은 이미 설명되었다(도 19 참조). 단계 2050 및 2060의 순서를 이 예와 똑같이 하는 것은 중요하지 않다.

또 하나의 API, update_cache(cache)(193)은 캐시 내의 모든 항목들이 현행하는지를 확인한다. 이는 캐시 내의 모든 오브젝트에 대해 OIB들을 검사하고 낡은 항목들을 무효화 또는 갱신함으로써 한다. 그 기능이 완료된 후 모든 오브젝트들이 현행하게 되어 일관성이 있게 되므로 의존성 리스트들을 무시한다.

관계예들

본 발명은 관계 데이터베이스의 일부일 수 있는 레코드들(이 레코드들은 바람직한 실시예에서 사용된 레코드들과 동의어가 아니다)을 취급하기 위한 특별한 특징들을 갖는다(1993년 Morgan Kaufmann의, J. Melton 및 A.R. Simon에 의한 "Understanding the New SQL:A Complete Guide(새로운 SQL의 이해: 완전 가이드)" 참조).

예를 들어, 관계 rel_name는 양쪽 모두 정수 형태인 age 및 weight의 속성들을 갖는다. 다음에 있어서: rel_name(age=25, weight=34)는 단일 레코드를 나타내며; rel_name(age=25)은 복수레코드 특정자(MRS)이고 age=25에 대한 rel_name에 속하는 모든 레코드들을 나타낸다.

본 발명은 단일 또는 복수의 레코드들에 상응하는 오브젝트들이 관리될 수 있도록 하는 특징들을 갖는다. 그러한 오브젝트들은 관계 오브젝트들로 알려져 있다. 단일 오브젝트는 동일 관계로부터의 복수의 레코드들을 나타낸다. 그러한 오브젝트는 복수 레코드 오브젝트(MRO)로 알려져 있는데 반하여 단일 레코드에 상응하는 오브젝트는 단일 레코드 오브젝트(SRO)로 알려져 있다. obj2에 상응하는 레코드들의 세트가 obj1에 상응하는 레코드들의 세트의 서브세트이면, MRO obj1은 또 다른 관계 오브젝트 obj2를 함유한다(포함한다). 오브젝트 관리자는 그것을 함유하고 있는 MRO에 관계 오브젝트로부터의 의존성들을 자동적으로 추가한다.

G 내의 모든 MRO 노드들에 대한 포인터들을 포함하고 의존성 정보 블록(DIB)(128)(도 16) 내의 relational_string 필드(1602)에 의해 알파벳순으로 색인되는 복수의 레코드 트리(MRT)(122)로서 알려진 밸런스된 트리를 오브젝트 관리자가 유지한다. 단일 관계 트리(SRT)로서 알려진 밸런스된 트리는 G 내의 모든 SRO 노드들에 대한 포인터들을 함유하고 DIB 내의 relational_string 필드(1602)에 의해 알파벳순으로 또한 색인된다. 이 설명으로부터 용이하게 구현되는 다른 접근 방식은, 단일 및 복수의 관계들에 대해서 단일의 밸런스된 트리를 유지하는 것이다. 또 다른 변형은 이 정보를 유지하기 위해 밸런스된 트리들 이외의 데이터 구조들을 사용하는 것이다.

본 발명에 따르면, 관계 오브젝트가 생성되기 전에, 관계가 API: define_relation(relation_name, list_of_attributes)(194)을 통해서 오브젝트 관리자에게 식별되어야만 한다.

list_of_attributes의 각 요소들은 속성의 이름 및 형태를 함유하는 쌍이다. API define_relation(194)은 관계 정보 영역(129)(도 12) 내에 관계에 관한 정보를 저장한다.

도 27은 단일 레코드 오브젝트(SRO)에 상응하는 노드를 생성하기 위한 로직의 일 예를 나타낸다. 단일 레코드에 상응하는 오브젝트는 단일 레코드 오브젝트(SRO)로 알려져 있음을 상기하여야 한다. 단일 관계 트리(SRT)로 알려진 밸런스된 트리는 G 내의 모든 SRO 노드들에 대한 포인터들을 함유하며 또한 DIB(도 16) 내의 relational_string 필드(1602)에 의해 알파벳순으로 색인된다. SRO에 상응하는 노드는 API create_sro_node(obj_id, initial_version_num, thresh_weight, relation_name, list_of_attribute_values) (190) (도 18a)을 통해서 생성된다. 이제 도 27을 참조하면, 단계 2300에서 모든 입력 파라미터들이 유효한지(예를 들어, 그들이 옳은 형태 등인지)를 결정한다. 또한 관계 "relation_name"가 관계 정보 영역(129)을 검사함으로써 define_relation(194)에 대한 호출을 통해서 이미 정의되었는지를 확인한다. 또한 list_of_attribute_values가 값들의 옳은 번호를 함유하고 모든 값들이 옳은 형태인지가 확인된다. 또 obj_id를 위한 노드 또는 동일 레코드에 상응하는 노드가 아직 존재하지 않는지가 확인된다(만일 obj_id를 위한 노드가 이미 존재하면 오래된 노드가 덮어 씌어지도록 수정하는 것은 용이할 것이다). 또한 동일 obj_id를 가진 복수의 노드들이 존재하도록 디자인을 수정하는 것도 용이할 것이다. 또 복수의 노드들이 동일 레코드에 상응하도록 허여하는 것도 용이하게 될 것이다. 만일 모든 파라미터들이 유효하다고 결정되면, 프로세싱은 단계 2305에서 계속된다. 그렇지 않으면, create_sro_node는 적절한 상태 메시지를 가지고 단계 2320에서 리턴한다.

단계 2305에서, object_id(160)를 obj_id로; version_num(161)을 initial_version_num으로; threshold_weight(168)를 thresh_weight로; 그리고 relational_string(1602)을 속성 값들 모두에 결부되어 있는 relation_name으로 초기화함으로써 G 내에 새로운 노드가 생성된다. relational_string(1602)을 포함하는 관계 및 속성 값들은 바람직하게는 구획자들(delimiters)에 의해 모두 분리된다. 그 방법은 relational_string(1602)으로부터 용이하게 관계 및 각 속성 값을 식별하는 것을 용이하게 한다. multiple_records(1603) 필드(도 16)는 거짓으로 설정된다. 단계 2310에서, 노드에 대한 포인터가 SRT에 추가된다. SRT 내의 새로운 포인터의 위치는 relational_string(1602)으로부터 결정된다. 단계 2315에서 obj_id로부터의 의존성들이 그것을 함유하는 복수의 레코드 오브젝트(MRO) 각각에 추가된다. 그러한 MRO들은 복수의 레코드 트리 MRT(122)를 검사함으로써 발견된다. MRT는 바람직하게는 G 내의 모든 MRO 노드들에 대한 포인터들을 함유하는 밸런스된 트리이고 의존성 정보 블록(DIB)(128)(도 16) 내의 relational_string(1602)에 의해 알파벳순으로 색인된다. 그것은 단지 relation_name을 위한 MRO들을 검사하는 것만을 필요로 한다. 그러한 MRO들 모두는 n이 MRO들의 총수이고 m이 relation_name을 위한 MRO들의 수인 경우에 O(log(n)+m)로 식별될 수 있다.

obj_id를 함유하는 각각의 MRO "obj2_id"에 대해서, obj_id에서 obj2로의 의존성이 생성된다. 다시 도 16을 참조하면, 의존성은 바람직하게는 obj2_id를 위한 mro_dep_weight(1604)의 웨이트로 초기화된다. obj2_id를 위한 threshold_weight(168)는 obj2_id를 위한 mro_threshold_increment(1605) 만큼씩 증가된다. 그 알고리즘의 단순한 확장은 웨이트들을 의존성에 할당하고 threshold_weight(168)를 수정하기 위한 다른 테크닉들을 사용하는 것이다. 이제 도 27을 참조하면, 프로세스는 상태 메시지를 가지고 리턴한다. 단계 2305, 2310 및 2315의 순서는 변할 수 있다. 더욱이, 이들 단계들은 동시에 실행될 수도 있다.

도 28은 복수의 레코드 오브젝트들(MRO들)을 생성하기 위한 로직의 일 예를 나타낸다. MRO들은 API: create_mro_node(obj_id, initial_version_num, thresh_weight, relation_name, list_of_attribute_conditions, rel_default_weight, rel_default_threshold) (191)(도 18a)를 통해서 생성되며, attribute conditions는: =25; >96; >45 및 <100; 등이다. attribute condition은 또한 속성 값에 어떠한 제한도 없음을 나타내는, 0(null) 일 수도 있다.

단일 오브젝트는 동일 관계로부터의 복수의 레코드들을 나타낼 수 있음을 상기하여야 한다. 그러한 오브젝트는 복수 레코드 오브젝트(MRO)로 알려져 있으며 단일 레코드에 상응하는 오브젝트는 단일 레코드 오브젝트(SRO)로 알려져 있다. 만일 obj2에 상응하는 레코드들의 세트가 obj1에 상응하는 레코드들의 세트의 서브세트이면, MRO obj1은 또 하나의 관계 오브젝트 obj2를 함유한다. 오브젝트 관리자는 그것을 포함하는 MRO에 관계 오브젝트로부터의 의존성을 자동적으로 추가한다. 오브젝트 관리자는 또한 G 내의 모든 MRO 노드들에 대한 포인터들을 함유하는 복수의 레코드 트리(MRT)(122)로 알려진 밸런스된 트리를 유지하며 의존성 정보 블록(DIB)(128)(도 16) 내의 relational_string(1602)에 의해 알파벳순으로 색인된다. 단일 관계 트리(SRT)로 알려진 밸런스된 트리는 G 내의 모든 SRO 노드들에 대한 포인터들을 함유하고 또한 DIB 내에 relational_string(1602)에 의해 알파벳순으로 색인된다.

도시된 바와 같이, 단계 2600에서, 모든 입력 파라미터들이 유효한지(예를 들어, 그들이 옳은 형태인지, 등)가 결정된다. 또한, 관계 정보 저장 영역(129)(도 12)을 검사함으로써 define_relation(194)(도 18a)에 대한 호출을 통해서 이미 관계 "relation_name"이 정의되었는지가 확인된다. 또한 list_of_attribute_conditions가 유효하고; obj_id를 위한 노드 또는 레코드들의 동일 세트에 상응하는 노드가 아직 존재하지 않는지가 확인된다. 이 기술분야의 숙련자들은 obj_id를 위한 노드가 이미 존재하면 오래된 노드가 덮어 씌어지도록 디자인을 수정하는 것이 용이하다는 것을 알 수 있을 것이다. 또한 복수의 노드들이 레코드들의 동일 세트에 상응하도록 하는 것도 용이할 것이다. 만일 단계 2600의 결과가 모든 파라미터들이 유효하다고 결정되면, 프로세싱은 단계 2605에서 계속된다. 그렇지 않으면, create_mro_node는 적절한 상태 메시지를 가지고 단계 2620에서 리턴한다.

단계 2605에서, (도 16을 또한 참조하면) object_id(160)를 obj_id로, version_num(161)을 initial_version_num으로, threshold_weight(168)를 thresh_weight로, relational_string(1602)을 속성 조건들 모두에 결부되어 있는 relation_name 필드로 초기화함으로써 G(도 17)내에 새로운 노드가 형성된다. relational_string(1602)을 구비하는 관계 및 속성 조건들은 구획자들에 의해 모두 분리된다. 그 방법에서, relational_string(1602)으로부터 용이하게 관계 및 각 속성 조건들을 식별하는 것은 용이하다. multiple_records(1603) 필드는 참으로 설정되고; mro_dep_weight(1604)는 rel_default_weight로 설정되고; mro_threshold_increment(1605)는 rel_default_threshold로 설정된다.

단계 2610에서, 노드에 대한 포인터가 MRT에 추가된다. MRT 내에서 새로운 포인터의 위치는 relational_string(1602)에 의해 결정된다. 단계 2615에서 obj_id로부터의 의존성들이 그것을 포함하는 각 MRO에, 단계 2315에서와 동일한 방식으로, 추가된다.

obj_id에 의해 함유된 각 오브젝트 obj2_id에 대해서, 단계 2625에서 obj2_id로부터 obj_i로의 의존성이 추가된다. 그러한 의존적인 오브젝트들은 MRT(122) 및 SRT(123)의 양쪽을 검색하고 relation_name을 위한 다른 모든 관계 오브젝트들을 고려함으로써 발견된다. 각 의존성은 obj_id를 위한 mro_dep_weight(1604)의 웨이트가 할당된다. 각각의 그러한 의존성에 대해서, obj_id를 위한 threshold_weight(168)는 obj_id를 위한 mro_threshold_increment만큼씩 증가된다. 이 기술분야의 숙련자들은 의존성에 웨이트들을 할당하고 threshold_weight(168)를 수정하는데 다른 테크닉들이 사용될 수 있음을 알 수 있을 것이다. 단계 2620에서, create_mro_node는 상태 메시지를 가지고 리턴한다. 단계 2605, 2610, 2615 및 2625의 순서는 변할 수 있다. 더욱이 이들 단계들은 동시에 실행될 수도 있다.

한편, 관계 오브젝트 obj1로부터 그것을 함유하는 MRO obj2로의 의존성의 웨이트는 obj1 내에 또한 포함되어 있는 obj2에 상응하는 레코드들의 비율 및 중요도에 근거할 수 있다. 이러한 변형은 단계 2315, 2615 또는 2625에 적용될 수 있을 것이다. 또 다른 변형은 어떠한 MRO도 다른 것의 서브 세트가 아니지만 2개의 MRO들이 하나 이상의 레코드를 공통으로 가질 때, 이들 MRO들간의 의존성들을 선택적으로 부가하는 것일 것이다.

이제 도 16을 참조하면, 이 기술분야의 숙련자들은 본 발명의 사상 및 범주 내에서, 오브젝트가 create_sro_node(190) 또는 create_mro_node(191) API들을 통해서 정의된 후, API들이 relational_string(1602), multiple_records (1603), mro_dep_weight(1604) 및 mro_threshold_increment(1605)를 수정하기 위해서 추가될 수 있음을 알 수 있을 것이다.

하나 이상의 레코드들이 변할 때, 오브젝트 관리자는 이를 API들(도 18a): record_has_changed (relation_name, list_of_attribute_values) (195) 및 records_have_changed (relation_name, list_of_attribute_conditions) (196)를 통해서 통지 받을 수 있다. 이들 API들은 의존성 계층구조를 통해서 변경들을 자동으로 전파할 것이다.

도 29a는 어떻게 records_have_changed(relation_name, list_of_attribute_conditions) (196) API가 구현될 수 있는지의 예를 나타낸다. 이 기술분야의 숙련자들은 그것으로부터 record_has_changed(relation_name, list_of_attribute_values) (195) API를 구현하는 것이 단순하다는 것을 알 수 있을 것이다.

도시된 바와 같이, 단계 2700에서, 입력 파라미터들이 유효한지가 결정된다. 또한 관계 정보 영역(129)(도 12)을 검사함으로써 관계 relation_name이 (define_relation(194) API (도 18a)를 통해) 이미 정의되었는지가 확인된다. 또한 list_of_attribute_conditions가 유효한지가 확인된다. 만일 입력 파라미터들이 유효하면, 프로세싱은 단계 2710으로 진행한다. 그렇지 않으면, 단계 2730에서 적절한 상태 메시지를 가지고 절차가 중지(abort)된다.

단계 2710에서, 모든 관계 오브젝트들은 어느 것이 변경된 적어도 하나의 레코드를 포함하는지를 발견한다. 이는 relation_name에 상응하는 MRT(122) 및 SRT(123)(도 12) 상에 모든 관계 오브젝트들을 검사함으로써 행해진다. 단계 2720에서, 단계 2710에서 정의된 모든 오브젝트들의 리스트 상에 objects_have_changed(189) API를 호출함으로써 G 내에 다른 노드들로 변경들이 전파될 수 있다.

끝으로, 단계 2730에서, records_have_changed는 적절한 상태 메시지를 가지고 리턴한다.

records_have_changed API의 단순한 변형으로는 G를 통해서 변경 정보를 어떻게 전하는지를 결정함에 있어서 변화한 관계 오브젝트 내에 레코드들의 비율 및 중요도를 고려하는 것일 것이다.

API compare_objects(obj_id, cache_id1, cache_id2)(192)(도 18b)는 cache_id1 및 cache_id2의 버전들이 얼마큼 유사한지를 결정하는데 사용될 수 있다. 예를 들어, version_num(141) 필드들은 2개의 버전들이 동일한지를 알아보기 위해 비교될 수 있다. 만일 그들이 다르다면, 하나의 오브젝트가 다른 것으로부터 얼마큼 더 가까운지를 나타내는 표시(indication)가, 예를 들어, version_num(141)과 timestamp(142) 필드들(도 14) 내에서의 차이가 제공될 수 있다.

만일 오브젝트의 2개의 버전들이 다르면, 0(최저 유사)에서 1(1은 오브젝트가 동일 버전들에 상응하는 것임)미만까지 변화되는 유사도 점수(similarity score)가 계산될 수 있다. 유사도 점수들은 바람직하게는, cache_id1 내의 obj_id에 일치하는 obj_id2의 버전이, cache_id2 내의 obj_id와 일치하는 obj_id2의 버전과 동일하게 되는, 그래프 오브젝트 obj_id2로부터 obj_id로의 인입 의존성들의 웨이트들의 합에 기초한다. 유사도 점수(SS)는 다음 공식을 사용하여 계산될 수 있다:

SS=common_weight/sum_weight(167), 단 common_weight는 그래프 오브젝트들 obj_id2로부터 obj_id로의 엣지들에 상응하는 웨이트(165)의 합과 같고, 그 엣지들에 상응하는 version_num(153) 필드들은 obj_id의 양 버전들에 있어서 동일함. compare_objects 로직은 또한 2개의 버전들이 아주 비유사한지 그렇지 않은지를 결정하는데 사용될 수도 있다. 단지 common_weight<threshold_weight인 경우에만 그들은 매우 비유사하다.

확장예들

본 발명에 대한 단순한 확장은 OIB들(도 14) 내에 threshold_weight 필드들을 포함하고 캐시들(2')(도 13)로 하여금 이들 필드들을 독립적으로 설정하게 하는 것일 것이다. 또 다른 단순한 확장은 서로 다른 캐시들에 상응하는 동일 오브젝트를 위해 서로 다른 일관성 리스트들을 허여하는 것일 것이다.

또 다른 확장은 그래프 오브젝트 obj1에서 또 다른 그래프 오브젝트 obj2로의 복수의 의존성들이 서로 다른 웨이트들을 가지고 존재할 수 있는 시스템일 것이다. 애플리케이션 프로그램은 이들 복수의 의존성들을 독립적으로 수정할 수 있을 것이다.

여전히 또 다른 확장은 오브젝트에 대한 낡은 링크들에 기초하여 오브젝트가 낡은 때를 결정하기 위한 다른 알고리즘들을 사용하는 것일 것이다.

그래프 오브젝트들이 변할 때, 바람직한 실시예는 의존성 그래프 G를 통해 정보를 전파할 때 그래프 오브젝트가 어떻게 변하는지를 고려하지 않는다. 단지 그래프 오브젝트가 변하였다는 사실만을 고려한다. 확장은 다른 그래프 오브젝트들에 대한 변경들을 전파하기 위하여 그래프 오브젝트들이 어떻게 변하는지를 또한 고려하는 것일 것이다. 이는 다음 방법들로 행해질 수 있을 것이다:

1. object_has_changed와 같은 기능들에 대한 파라미터들을 통해서 그래프 오브젝트가 어떻게 변하였는지에 관한 추가적인 정보를 제공함. 이 정보는 그래프 오브젝트로부터 그의 값을 의존하는 다른 그래프 오브젝트들로의 링크들을 수정하는데 사용되고, 이어서 그래프 오브젝트의 승계자들(successors)이 어떻게 변하였는지를 결정하는데 사용될 것이다.

2. 오브젝트 관리자(120)가 그래프 오브젝트 o2가 변하였다고 결정할 때, 오브젝트 관리자는 다음 2가지를 고려할 것이다: 그의 선임자들(predecessors)중 어느 것이 변하였는지; 그리고 선임자들이 어떻게 변하였는지에 관해 반복적으로 수집한 어떤 정보. 오브젝트 관리자는 그 때 o2가 어떻게 변하였는지를 결정하기 위해 이 정보를 사용할 것이다. o2가 어떻게 변하였는지에 관한 정보는 o2에 의존하는 다른 그래프 오브젝트들로의 링크들을 수정하는데 사용되고 이어서 o2의 승계자들이 어떻게 변하였는지를 결정하는데 사용될 것이다.

예를 들어, 도 29b를 고려하자. u2 및 u3은 변화한 하부 데이터들이다. 오브젝트 관리자는 o1 및 o3으로 변경 정보를 전파한다. 오브젝트 관리자가 o2로 변경 정보를 전파할 때, o2의 캐시된 사본들을 어떻게 갱신 또는 무효화할 것인지를 결정함에 있어서 o1 및 o3으로부터 o2로의 엣지들의 웨이트들만을 고려하는 것이 아니라, u2, u3, o1, o3에 대한 변경들의 성질도 또한 고려한다. 이 정보는 o4의 캐시된 버전들을 어떻게 갱신 또는 무효화할 것인지를 결정하는데 또한 사용될 수도 있다.

다른 응용예들

본 발명은 애플리케이션이 하부 데이터를 갱신할 것인지의 여부에 관한 결정을 해야만 하는 시스템에서도 또한 사용될 수 있다. 오브젝트 의존성 그래프를 검사함으로써, 시스템은 하부 데이터에 대한 변경들에 의해 영향을 받은 다른 오브젝트들을 결정할 수 있다. 만일 이러한 세트가 충족되면, 변경들이 이루어질 수 있을 것이다. 그렇지 않으면, 시스템은 하부 데이터에 대한 변경이 이루어지지 않도록 할 것이다.

이 기술분야의 숙련자들은 효율적으로 동작들을 스케줄하기 위해서 컴파일러, 런-타임 시스템 또는 데이터베이스에 의해 본 발명이 또한 사용될 수 있음을 알 수 있을 것이다. 서로 다른 스케줄들은 하부 데이터에 대한 서로 다른 변경들을 가져올 것이다. 오브젝트 의존성 그래프를 분석함으로써, 스케줄을 결정하는 프로그램은 동작들을 스케줄하는 유망한 방법을 결정할 수 있을 것이다.

캐시들을 유지하고 일관되게 갱신하는 확장가능한 방법에 대한 상세한 설명

본 발명의 이 실시예는 네트워크에 의해 연결된 하나 이상의 물리적 (컴퓨터) 시스템들의 집합(collection) 상에서 작동할 수 있도록 디자인된다. 이러한 시스템의 집합에 상주하는 본 발명의 예는 하나 이상일 수 있다. 사전적인 의미가 또한 내포되지만, 다음 정의들이 본 발명의 복수의 예들을 구별하는 지침으로서 제공된다.

오브젝트 소스(object sources): 오브젝트 소스는 DB2라는 상표명으로 IBM에서 판매하는 제품, LOTUS NOTES 및 DOMINO 서버라는 상표명으로 Lotus 상에서 판매하는 제품과 같은 하나 이상의 제품들, 또는 (HTML 페이지들과 같은) 보다 복합 오브젝트들이 만들어지는 근거가 되는 오브젝트들 또는 데이터를 포함하는 다른 소스들(3030)을 포함한다.

트리거(Trigger): 데이터에서의 수정에 응답하여 자동적으로 동작들을 일으키는데 사용될 수 있는 어떤 수단. 트리거는, 데이터에서의 수정에 응답하여 동작들을 자동으로 일으키기 위한, DB2라는 상표명으로 IBM에 의해 그리고 LOTUS NOTES 및 DOMINO 서버라는 상표명들로 Lotus에 의해 판매되는 것과 같은 많은 표준 오브젝트 소스들의 표준적인 특징이다. 본 발명의 일 실시예는 데이터와 동기하는 오브젝트 소스 내에 저장된 데이터로부터 만들어진 오브젝트들을 유지하기 위한 신규한 방법으로 트리거들을 사용한다.

트리거 통지(Trigger Notification): 이는 오브젝트 소스 내에서 호출되는 트리거에 응답하여 본 발명으로 보내지는 메시지이다.

캐시 트랜젝션(Cache transactions): 캐시 오브젝트들을 읽거나, 갱신하거나, 또는 삭제하기 위한 캐시 관리자로의 요구들을 포함함. 연관된 원격 데이터에 동기하여 캐시 관리자에 의해 관리되는 캐시 내의 오브젝트를 유지하기 위한 본 발명에 따른 로직의 일 예임. 트리거 모니터는 하부 데이터에 동기하여 캐시 관리자에 의해 관리되는 캐시 내에 저장된 복합 오브젝트들을 유지할 목적으로 원격 데이터 소스들을 모니터링하는 단일의 장기 실행 프로세스일 수 있다.

마스터 트리거 모니터(Master Trigger Monitor): 이는 트리거 통지를 수신하는 트리거 모니터의 예이다.

슬래이브 트리거 모니터(Slave Trigger Monitor): 이는 마스터 트리거 모니터(3000')로부터의(즉 직접적으로 오브젝트 소스들로부터가 아닌) 트리거 통지들이 그에게로 전해지는 트리거 모니터의 일 예이다.

로컬 캐시(Local Cache): 이는 캐시 그 자체와 동일한 물리적 머신 상에 상주하는 트리거 모니터의 일 예에 의해 갱신되는 캐시(또는 파일 시스템과 같은 다른 표준 오브젝트 저장소)이다.

원격 캐시(Remote Cache): 이는 캐시 그 자체와 다른 물리적 머신 상에 상주하는 트리거 모니터의 일 예에 의해 갱신되는 캐시(또는 파일 시스템과 같은 다른 표준 오브젝트 저장소)이다.

본 발명은 (만일 트리거 이벤트들을 수신하면) 마스터(3000) 및 (어떤 마스터로부터 트리거 이벤트들의 통지들을 수신하면) 슬래이브(3000a)의 양쪽 모두의 역할을 하는 것이 가능하다.

이제 도면들을 참조하면, 도 30a는 본 발명의 특징들을 갖는 시스템의 예를 나타내는 블록도이다. 도시된 바와 같이, 시스템은 (하나 이상의) 원격 노드들(3108)을 포함한다. 노드들(3108)은 (httpd(3080)로 표시된) 웹 서버들을 통해서 클라이언트들로 웹 페이지들을 제공하는 서버들일 수 있다. 각 웹 서버는 데이터베이스(3010)로부터 구축되는 동적 웹 페이지들의 주요한 부분을 제공할 수 있다. 그러한 각 서버 노드(100)는, 웹 페이지들을 발생하는데 관련된 비용 때문에, 동적 웹 페이지들과 같은 복합 오브젝트들을 포함하는 하나 이상의 오브젝트들(3004)을 캐시한다. 동일한 동적 웹 페이지에 대한 복수의 요구들은 캐시(3003)로부터 충족될 수 있으므로, 오버헤드를 줄일 수 있다.

복수의 서버 노드들(3108)의 사용은 시스템이 서비스할 수 있는 요구들의 양을 증가시킨다. 비록 요구사항은 아니지만 서버 노드들(3108)은 지리적으로 멀리 떨어져 있을 수 있다.

본 발명에 따르면, 캐시(3003) 내에 저장된 하나 이상의 오브젝트들(3004)의 값에 영향을 줄 수도 있는, 데이터베이스(3010)와 같은 오브젝트 소스에 대한 변경이 일어날 때, 트리거 모니터(3000)는 변경된 값들을 갖는 오브젝트들을 각 캐시 관리자(3001)로 통지한다. 트리거 모니터(3000)는 그의 캐시 내에 오브젝트(3004)가 변하였음을 캐시 관리자(3001)에게 통지할 수도 있다. 이 경우에, 캐시 관리자(3001)는 오브젝트(3004)의 사본을 무효화할 수 있다. 한편, 트리거 모니터(3000)는 오브젝트(3004)가 변경되었음을 캐시 관리자(3001)에게 통지하고 오브젝트(3004)의 새로운 값을 또한 제공할 수도 있다. 이 기술분야의 숙련자들은 오브젝트(3004)에 대한 새로운 값이 원격 노드(3108) 또는 어떤 중간, 예를 들어 프록시 노드뿐만 아니라 데이터 서버 노드(3102) 상에서 계산될 수 있음을 알 수 있을 것이다. 어느 하나의 대안에 있어서, 캐시 관리자는 오브젝트(3004)를 동적으로 갱신하는 옵션, 예를 들어 그것을 무효화하지 않고 새로운 버전을 저장하는 옵션을 가질 수 있을 것이다.

도 30b는 트리거 모니터(3000)의 보다 구체적인 예를 나타낸다. 여기서, 트리거 모니터(3000)는 마스터 트리거 모니터(3000')로서 예시된다. 도시된 바와 같이, 복합 오브젝트들(3004)을 포함하는 캐시들(3003)의 유지는 트리거 모니터(3000)라 불리는 본 발명에 따른 프로세스(또는 프로세스들의 집합)에 의해 행해진다. 트리거 모니터(3000)는 바람직하게는 하부 데이터에 동기하는 캐시 관리자(3001)의 내용들을 유지할 목적으로 데이터 소스들(3050)을 모니터링하는 단일의 장기 실행 프로세스이다. 마스터 트리거 모니터(3000')는 트리거 이벤트들(3020)을 수신하는 트리거 모니터(3000)의 일 예이다. 마스터 트리거 모니터(3000')는: 트리거 모니터 드라이버(3040); 오브젝트 Id 분석(3041) 로직; 오브젝트 발생기(3042) 로직; 및 분배 관리자(3043)를 포함한다.

마스터 트리거 모니터(3000')는, 오브젝트 소스들(3050), (로컬 캐시 관리자로 알려진) 캐시 관리자(3001), 및 0 또는 그 이상의 (슬래이브) 트리거 모니터(3000")(도 30c)와 다른 물리적 머신들 상에 상주하는 원격 캐시 관리자(3002)와 함께 작동한다. 오브젝트 소스들은(3050)은, (HTML 페이지들과 같은) 더 복합적인 오브젝트들이 그로부터 만들어지는, 하나 또는 그 이상의 엔터티들: 예를 들어 IBM사에 의해 상표명 DB2로 판매되는 데이터베이스(3010); 또는 Lotus 사에 의해 상표명 DOMINO로 판매되는 서버와 같은 다른 어떤 소스들(3030)을 포함한다

오브젝트 소스(3050)가 변경을 검출할 때, 트리거가 호출된다. 상기한 바와 같은 많은 표준 오브젝트 소스들(3050)의 표준적인 특징인, 트리거는 전형적으로 데이터의 수정에 응답하여 자동으로 동작들을 일으키는데 사용된다. 본 발명은 데이터에 동기하여 오브젝트 소스 내에 저장된 데이터로부터 만들어진 오브젝트(3004)를 유지하기 위한 신규한 방법에서 트리거들을 사용한다. 트리거 모니터 드라이버(3040)로 메시지가 송신되게 하는 send_trigger(3026) API(도 30d 참조)는 트리거와 관련되어 있다. 응답하여, 트리거 모니터 드라이버(3040)는 그 때 트리거 이벤트(3020)라 불리는 트랜젝션(도 30e 참조)을 발생할 수 있다.

트리거 이벤트(3020)는 레코드 ID(3012) 내로 (일반적인 수단에 의해) 번역(translation)되고 번역을 위해 캐시 관리자(3001)로 전해질 수 있다. 캐시 관리자(3001)는 오브젝트 Id 분석(OIA) 요소(3041)에 엔큐(enqueue)하고 있는 오브젝트 ID들(3009)의 상응하는 리스트로 리턴한다. OIA(3041)는, 잘 알려진 수단에 의해, 각 오브젝트 ID(3009)마다 하나씩, (후술하는) 오브젝트 배치 블록들(ODB)(3100)의 세트를 발생한다.

도 31은 오브젝트 배치 블록(ODB)(3100)의 일 예를 나타낸다. 오브젝트 ID(3009)는 오브젝트들을 대체하거나 또는 삭제하려고 할 때 캐시(3003)에서 오브젝트(3004)를 식별하는데 사용된다. 캐시 Id(3200)는 캐시들(3003)중 어느 것에 오브젝트들(3004)이 속하는지를 식별하는데 사용된다. 외부 ID(3101)는 오브젝트 발생기(3042)가 오브젝트를 알 수 있도록 하는 추가적인 식별자이다. 요구 배치(request disposition)(3103)는 갱신 오브젝트 요구(3022) 또는 삭제 원격 오브젝트 요구(3025)(도 30e)를 발생시키기 위하여 오브젝트 발생기에 의해 사용된다. 만일 요구 배치(3103)가 DispRegenerate(3130)이면, ODB(3100)에 의해 표시되는 오브젝트들(3004)은 시스템에 의해 다시 발생되어 분배된다. 만일 요구 배치(3103)가 DispInvalidate(3131)이면, 오브젝트들(3004)은 모든 시스템들로부터 삭제된다.

도 32는 캐시 ID(3200)의 일 예를 나타낸다. 도시된 바와 같이, 캐시 ID는 바람직하게는 캐시 이름(3201), 캐시 호스트(3202) 식별자 및 캐시 포트(3203) 식별자를 포함한다.

이제 도 30b를 참조하면, ODB(3100)는 오브젝트 발생기(3402)로 보내진다. 오브젝트 발생기는 ODB(3100)를 검사하고 다음 중 하나를 행한다: a) 삭제 원격 오브젝트 요구(3025)를 발생함; b) 오브젝트 소스들(3050)과의 연결을 설립하고, 오브젝트(3004)를 다시 만들고, 갱신 오브젝트 요구(3022)를 생성함.

TMD(3040)는 그 때 삭제 원격 오브젝트 요구(3025) 또는 갱신 오브젝트 요구(3022)를 분배 관리자(3043)로 전한다.

분배 관리자(3043)는 구성된(configured) 원격 캐시 관리자(3002) 또는 슬래이브 트리거 모니터(3000")(도 30c)와의 연결을 설립하고, 각각의 요구를 전달한다. 만일 요구가 포워드 트리거 요구(3021)이면, 요구는 슬래이브 트리거 모니터(3000")(도 30a)로 보내진다. 만일 요구가 갱신 오브젝트 요구(3022)이면, 새로운 오브젝트가 원격 캐시 관리자(3001)로 cache_object(410) API(도 4)를 통해 보내진다. 만일 요구가 삭제 원격 오브젝트 요구(3025)이면, 오브젝트(3004)는 delete_object(420) API(도 4)를 통해서 각각의 원격 캐시관리자(3001)로부터 제거된다.

도 30c는 트리거 모니터(3000)의 또 다른 예를 나타낸다. 여기서, 트리거 모니터(3000)는 슬래이브 트리거 모니터(3000")로서 예시된 것이다. 만일 마스터 트리거 모니터(3000')가 하나의 시스템을 정확히 유지하고 있는 중이거나, 또는 오브젝트(3004)가 다시 발생되는 (즉, 삭제되지 않고) 것이면, 도 30b에 기재된 바와 같은 프로세스를 사용하여 전적으로 유지될 수 있다. 만일 트리거 모니터(3000)가 복수의 시스템들을 유지하고 있는 중이면, 오브젝트(3004)가 모든 캐시들은 아니지만 몇몇의 캐시들에 존재하는 것이 가능하다. 특히, 오브젝트(3004)는 트리거 이벤트(3020)를 수신한 트리거 모니터(3000)로서 동일 캐시 내에 존재하지 않을 수 있다. 이러한 경우를 취급하기 위하여 슬래이브 트리거 모니터(3000")(도 30c)는 각각의 구성된 노드 상에서 실행된다. 이것은 오브젝트 발생기(3042) 내에 그것이 도착할 때까지 트리거 이벤트(3020)와 동일하게 프로세스된다. 만일 오브젝트 배치 블록(3100)이 DispRegenerate(3130)와 동등한 요구 배치(3103)를 가지면, 요구는 폐기된다. 만일 요구 배치(3101)가 DispInvalidate(3131)이면, 삭제 로컬 오브젝트 요구(3023)가 만들어져 슬래이브의 로컬 캐시로 보내진다.

다시 도 30을 참조하면, 트리거 모니터(3000)는 바람직하게는 오브젝트 소스들(3050)을 모니터링하는, 단일의 장기 실행 프로세스로서 구체화된다. 이 기술분야의 숙련자는 시스템의 스루풋을 개선하기 위해 시간적으로 일부가 중복되는 요소당 하나 이상의 프로세스들을 구성하기 위해서, 본 발명을 용이하게 개조(adapt)할 수 있을 것이다. 이 기술분야의 숙련자는 또한, 만일 하부 시스템이 스레드된 프로세스들을 지원하면, 각각의 스레드가 하나 이상의 요소들을 구현하며 그 몇몇이 시간적으로 중복될 때, 단일 프로세스에서 동작의 복수 스레드들을 사용하기 위하여 본 발명을 용이하게 개조할 수 있을 것이다.

멀티페이즈 커미트(multiphase commit) 및 영구 데이터 오브젝트들(persistent data objects)과 같은 일반적인 메커니즘들은, 이러한 요구들이 일단 전달되면 완료될 때까지 시스템에 남아있음을 오브젝트 소스들(3050)에게 보증하기 위하여, 트리거 이벤트들(3020) 및 포워드 트리거 요구들(3021)을 수신할 때 바람직하게 사용된다. 재시도(retry) 및 멀티페이즈 커미트와 같은 일반적인 메커니즘이 완료될 때까지 시스템 내에 엔큐된 아웃바운드 요구들(enqueued outbound requests)(도 30e에 도시됨)이 남아있음을 보증하기 위하여 바람직하게 사용된다.

오브젝트 Id 분석(OIA) 요소(3041)는 오브젝트 배치 블록(ODB)(3100)(도 31) 내로 오브젝트 ID들(3009)을 번역한다. OIA(3041)는 구성 옵션, API, 또는 다른 어떤 표준 방식으로서 특정되고 인터페이스될 수도 있다. 이 기술분야의 숙련자는 용이하게 그러한 메커니즘을 만들 수 있을 것이다.

오브젝트 발생기(3042)는 도 30c에서 도시되어 있고 후술하는 트랜젝션 형태들 내로 오브젝트 배치 블록(ODB)(3100) 내의 정보를 번역한다. 트리거 모니터(3000)는 구성 옵션(configuration options), API, 또는 다른 어떤 표준 테크닉을 사용하여 이러한 콤포넌트에 대한 인터페이스를 제공한다. 오브젝트 발생기들(3042)의 예들은: 상표명 NET.DATA로 IBM사에 의해 판매되는 제품; 상표명 DOMINO 서버로 Lotus사에 의해 판매되는 제품; 또는 그로부터 HTML 페이지들을 페치(fetch)할 수 있는 어떤 웹 서버 제품들이다.

도 30d는 send_trigger API의 일 예를 나타낸다. 도시된 바와 같이, send_trigger(3026) API는 오브젝트 소스들(3050)이 트리거 모니터 드라이버(3040)와 통신할 수 있도록 한다. send_trigger(3026) API는 트리거를 고유하게 식별하고 트리거 이벤트(3020)를 구축하기에 충분한 정보(메시지 파라미터들)를 포함하는 메시지를 송신한다. 이 기술분야의 숙련자는 (가변-길이 파라미터 리스트들과 같은) 표준 테크닉들을 사용하여 그 정보를 용이하게 정의하고 특정할 수 있을 것이다.

도 30e는 본 발명에 따라 사용되는 트랜젝션 형태들의 예들을 나타낸다. 도시한 바와 같이, 몇몇의 트랜젝션들(3020, ..., 3025)은 시스템 내에서 발생될 수 있다.

트리거 이벤트(3020)는 send_trigger(3026) API를 통해 보내진 메시지의 수령에 응답하여 발생된다. 트리거 이벤트(3020)는 send_trigger(3026) API에 의해 보내진 데이터를 하나 이상의 표시 의존적 오브젝트 요구들(3024)로 번역하고 시스템을 통해서 그 자체를 적절히 추적 및 가이드하기에 충분한 정보를 유지하는 구조이다.

포워드 트리거 요구(3021)는 send_trigger(3026) API를 통해 보내진 트리거 이벤트(3020)의 수령에 응답하여 발생된다. 포워드 트리거 요구(3021)는 하나 이상의 표시 의존적 오브젝트 요구들(3024)을 발생하고 시스템을 통해서 그 자체를 적절히 추적 및 가이드 하는데 충분한 정보를 유지하는 구조이다.

갱신 오브젝트 요구(3022)는 분배 관리자(3043)를 통해서 새로운 오브젝트들이 원격 캐시 관리자(3002)에게 분배되도록 하기 위해 오브젝트 발생기(3042)에 의해 발생된다. 갱신 오브젝트 요구는 어떤 임의 캐시(arbitrary cache)(3003)에서 오브젝트를 대체하기에 충분한 정보를 유지하는 구조이다.

삭제 로컬 오브젝트 요구(3023)는 로컬 캐시(3003)가 오브젝트(3004)를 삭제하도록 하기 위해 오브젝트 발생기에 의해 발생된다. 삭제 로컬 오브젝트 요구(3023)는 로컬 캐시 관리자(3001)로부터 오브젝트(3004)를 삭제하기에 충분한 정보를 유지하는 구조이다.

표시 의존적 오브젝트 요구(Show Dependent Object Request)(3024)는 로컬 캐시 관리자(3001)로부터 의존성 정보를 요구하는 트리거 이벤트(3020)에 응답하여 트리거 모니터 드라이버(3040)에 의해 발생된다. 표시 의존적 오브젝트 요구(3024)는, 로컬 캐시 관리자(3001)로부터 오브젝트 ID들(3009)을 얻기 위하여 트리거 이벤트(3020) 또는 포워드 트리거 요구(3021)를 분석하고 API show_dependent_objects(3024)를 호출하기에 충분한 정보를 유지하는 구조이다.

삭제 원격 오브젝트 요구(3025)는, 오브젝트(3004)가 분배 관리자(3043)를 통해서 원격 캐시 관리자들(3002)로부터 삭제되도록 하기 위해 오브젝트 발생기(3042)에 의해 발생된다. 삭제 원격 오브젝트 요구(3025)는 임의 캐시(3003)로부터 오브젝트(3004)를 삭제하기에 충분한 정보를 유지하는 구조이다.

도 33은 트리거 모니터 드라이버(3040) 및 분배 관리자(3043)의 통신 경로들 및 하이-레벨 조직의 일 예를 나타낸다. 바람직한 조직은 독립적으로 실행되는 몇 개의 제어 스레드들로 구성된다.

수신 스레드(3300)는 트리거 이벤트(3020) 및 포워드 트리거 요구(3021)를 포함하는 요구들을 수신하고 그들을 어떤 영구 저장소에 저장한다. 인입 작업 디스패처 스레드(3320)는 3300으로부터의 인입 요구들을 디큐(dequeue)한다. 캐시 관리자 통신 스레드(3340)는 로컬 캐시 관리자(3060)로 삭제 로컬 오브젝트 요구(3023) 및 표시 의존적 오브젝트 요구(3024)를 보낸다. 오브젝트 발생기 스레드(3360)는 다음 오브젝트 요구들: 삭제 원격 오브젝트 요구(3025); 및 갱신 오브젝트 요구(3022)의 발생을 조정하고 분배를 위해 그들을 엔큐(enqueue)한다. (분배 관리자(3043)의 주요 콤포넌트인) 분배 스레드(3080)는 분배 관리자 큐(3370)로부터 요구들을 디큐하고 그들을 모든 아웃바운드 머신들로 엔큐한다. 아웃바운드 트랜젝션 스레드들(3395)은 원격 머신들과 접속하여 머신 아웃바운드 큐들(3390) 상에 엔큐된 작업들을 전송(forward)한다.

종래와 같이, 이들 스레드들은 몇 개의 FIFO 큐들: 인입 요구 큐(3310); 캐시 관리자 요구 큐(3330); 오브젝트 발생기 큐(3350); 분배 관리자 큐(3370); 및 머신 아웃바운드 큐들(3390)(분배된 캐시당 하나)을 통해 통신할 수 있다.

도 34는 수신 스레드(3300) 로직의 일 예를 나타낸다. 도시된 바와 같이, 단계 3410에서, 인입 메시지(send_trigger API(3026) 또는 포워드 트리거 요구(3021)의 어느 하나)는 시스템으로 들어가서 트리거 이벤트(3020)로 변환된다. 단계 3420에서, 메시지는 영구 큐(3450)에 수신 스레드(3300)에 의해 쓰여지고 단계 3430에서 인입 요구 큐(3310)에 엔큐된다. 단계 3440에서, 요구 형태가 체크된다. 단계 3460에서, 만일 그것이 트리거 이벤트(3020)이면, 포워드 트리거 요구(3021)는 분배 관리자 큐(3370)에 엔큐된다. 단계 3490에서, 수신 스레드(3300)는 작업 대기중인 3490으로 리턴한다.

도 35는 인입 작업 디스패처 스레드(3320) 로직의 일 예를 나타낸다. 도시된 바와 같이, 단계 3510에서, 인입 작업 디스패처 스레드(3320)는 작업 요구를 디큐한다. 단계 3520에서 표시 의존적 오브젝트 요구(3024)는 캐시 관리자 요구 큐(3330)에 엔큐된다. 단계 3590에서, 수신 스레드(3300)는 작업 대기중으로 리턴한다.

도 36은 캐시 관리자 통신 스레드(3340) 로직의 일 예를 나타낸다. 도시된 바와 같이, 단계 3610에서, 캐시 관리자 통신 스레드(3340)는 다음 요구를 디큐하고 로컬 캐시 관리자(3001)와의 통신을 설립한다. 단계 3023에서, 만일 요구가 삭제 로컬 오브젝트 요구이면, 단계 3650에서, delete_object(420) API가 로컬 캐시(3003)로부터 오브젝트를 삭제하기 위해 사용된다. 단계 3024에서, 만일 요구가 표시 의존적 오브젝트 요구이면, 단계 3620에서, show_dependent_objects(460) API가 오브젝트 ID들(3009)을 페치하기 위해 사용된다. 단계 3630에서, 오브젝트 ID들(3009)은 오브젝트 배치 블록(ODB)(3100)을 만드는 오브젝트 ID 분석(3042) 콤포넌트로 전해진다. 단계 3640에서, 오브젝트 배치 블록(3100)은 오브젝트 발생기(3043)에 엔큐된다. 끝으로, 단계 3690에서, 캐시 관리자 통신 스레드(3340)는 작업을 대치하는 3690으로 리턴한다.

도 37은 오브젝트 발생기 스레드(3360) 로직의 일 예를 나타낸다. 도시된 바와 같이, 단계 3710에서, 오브젝트 발생기 스레드(3360)는 큐(3350)로부터 다음 요구를 디큐한다. 단계 3720에서, 오브젝트의 배치가 체크된다. 만일 그것이 DispInvalidate(3131)이면 단계 3750으로 진행하고; DispRegenerate(3130)이면 단계 3730으로 진행한다. 단계 3730에서, RequestType이 체크된다. 만일 그것이 포워드 트리거 요구(3021)이면 단계 3770으로 진행하고; 만일 그것이 트리거 이벤트(3020)이면 단계 3740으로 진행한다. 단계 3740에서, 오브젝트들(3004)을 다시 발생하기 위하여 데이터 소스들(3050)이 접속된다. 새로운 오브젝트들(3004)은 분배 관리자 큐(3370)에 갱신 오브젝트 요구(3022)를 갖고 엔큐된다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3790으로 리턴한다.

단계 3750에서, RequestType이 체크된다. 만일 그것이 포워드 트리거 요구(3021)이면 단계 3780으로 진행하고; 만일 그것이 트리거 이벤트(3020)이면 단계 3760으로 진행한다. 단계 3760에서, 삭제 원격 오브젝트 요구(3024)가 만들어지고 분배 관리자 큐(3370)에 엔큐된다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3790으로 리턴한다.

단계 3770에서, 요구가 시스템으로부터 삭제된다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3790으로 리턴한다.

단계 3780에서, 삭제 로컬 오브젝트 요구(3023)가 캐시 관리자 요구 큐(3330)에 엔큐된다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3790으로 리턴한다.

도 38은 분배 관리자 스레드(3380) 로직의 일 예를 나타낸다. 도시된 바와 같이, 단계 3810에서 분배 관리자 스레드(3380) 로직은 분배 관리자 큐(3380)로부터 작업을 디큐하고 머신 아웃바운드 큐들(3390)의 각각으로 요구들의 사본을 엔큐한다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3790으로 리턴한다.

도 39는 아웃바운드 트랜젝션 스레드(3395) 로직의 일 예를 나타낸다. 분배된 갱신 스킴에 참여하는 머신 각각을 위해 하나의 아웃바운드 트랜젝션 스레드(3395)가 있다. 도시된 바와 같다. 단계 3910에서 스레드는 머신 아웃바운드 큐(3390)로부터 작업을 디큐하고 요구 형태를 체크한다. 단계 3920에서, 만일 그것이 갱신 오브젝트 요구(3022) 또는 삭제 원격 오브젝트 요구(3025)이면 프로세스는 단계 3920에서 계속되고; 만일 그것이 포워드 트리거 요구(3021)이면, 프로세스는 단계 3930에서 계속된다. 단계 3930에서, 트리거 모니터(3000)가 접속된다.

단계 3920에서 원격 캐시 관리자(3001)가 접속된다. 단계 3940에서, 만일 요구가 갱신 오브젝트 요구(3022)이면, cache_object API(410)이 새로운 오브젝트들(3004)을 원격 캐시 관리자(3002)로 보내기 위해 사용된다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3990으로 리턴한다. 단계 3950에서 만일 요구가 삭제 원격 오브젝트 요구(3025)이면, 원격 캐시 관리자(3002)로부터 오브젝트들(3004)을 삭제하기 위해 delete_object API(420)가 사용된다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3990으로 리턴한다.

단계 3930에서, 원격 트리거 모니터(3000a)가 접속된다. 단계 3960에서, 포워드 트리거 요구(3021)가 원격 트리거 모니터(3000a)로 보내진다. 그리고 나서 프로세스는 작업을 대기하기 위해 단계 3990으로 리턴한다.

확장예 및 변형예

여기서 반복되지 않는 다른 출구들(exits)은, 본 발명의 특정 애플리케이션에 따라, 트리거 이벤트들(3020)의 완전한 분석 및 (갱신 오브젝트 요구(3022) 또는 삭제 원격 오브젝트 요구(3025)와 같은) 동작들(actions)로의 번역을 위해 필요로 될 수도 있다.

예를 들어, 이제 도 40을 참조하면:

a) 출구를 통해서 단일의 트리거 이벤트(3020)를 복수의 표시 의존적 오브젝트 요구들(3024)의 세트로 번역하는 것이 유용할 수 있다;

b)갱신 오브젝트 요구(3022)에 앞서, 오브젝트 발생기(3042)에 의해 생성된 바와 같은 오브젝트들(3004)을 수정 또는 분석(4010)하는데 유용할 수 있다; 그리고

c) 캐시(3003)에 오브젝트들(3004)을 쓰는 것 대신에 또는 그에 덧붙여 파일 시스템에 오브젝트들(3004)을 쓰는데 유용할 수 있다.

트리거 모니터(3000)의 또 다른 용도는 캐시 내에 현재 존재하지 않을 수도 있는 오브젝트들을 취급할 목적으로 오브젝트들을 발생하고 분배하기 위하여 그의 능력을 다시 사용하는 것일 것이다:

a) prime_cache API(4020)는, 그 오브젝트들(3004)이 현재 어떤 캐시(3003)에게 알려져 있는지에 관계없이, 오브젝트 ID(3009)가 부여된 오브젝트들(3004)을 발생하고 분배하는데 사용될 수 있다.

b) global_delete API(4030)는, 오브젝트가 실제로 어떤 곳에 존재하는지를 모르는 체 시스템 내의 모든 캐시들(1)로부터 어떤 특정 오브젝트들(3004)이 제거됨을 보증하는데 사용될 수 있다.

트리거 모니터(3000)는, 요구들의 엄격한 FIFO 순서(ordering) 및 프로세싱을 시행하기 위해, 또는 요구들의 완전한 비동기 프로세싱을 가능하게 하기 위해, 또는 잘 알려진 임의의 스케줄링 스킴 또는 상기한 것들의 임의의 조합에 따라 요구들을 처리하기 위해, 구현될 수 있다.

일관성 유지

이미 여기서 논의한 바와 같이, 여기에서 사용된 용어들은 사전적인 의미들도 갖고 있으나, 몇몇의 용어들은 다음 용어해설이 지침을 제공한다:

트랜젝션 관리자는 상태를 관리하는 프로그램이다. 예들에는: 캐시들을 관리하는 캐시 관리자; DB2와 같은 데이터베이스 관리 시스템들; 그리고 CICS와 같은 트랜젝션 프로세싱 시스템들이 포함된다.

트랜젝션은 다른 프로그램에 의해 만들어진 트랜젝션 관리자에 대한 요구이다.

상태-변경 트랜젝션은 트랜젝션 모니터에 의해 관리되는 상태를 수정하는 트랜젝션이다. 캐시 오브젝트들을 읽거나, 갱신하거나, 또는 삭제하기 위한 캐시 관리자에 대한 요구들은 트랜젝션들을 구성할 것이다.

데이터 읽기 및 수정은 액세스들로서 알려진다.

잠금은 공유 데이터를 읽거나 또는 쓰는 프로세스들의 능력을 제한하는 엔터티이다. 프로세스가 하나의 데이터 상에 읽기 잠금을 획득할 때, 다른 프로세스들은 그 데이터에 액세스할 수 있으나 그 데이터를 수정할 수는 없다. 프로세스가 데이터 상에 쓰기 또는 배타적 잠금을 획득할 때, 다른 프로세스들은 그 데이터를 읽거나 또는 수정할 수 없다. 잠금들을 구현하는 몇 가지의 방법들이 선행 기술에 존재한다. 예를 들어, 1996년, Morgan Kaufmann의, Hennessy와 Patterson에 의한 "Computer Architecture: A Quantitative Approach(컴퓨터 구성: 정량적 접근방식)"의 제2판을 참조한다.

하나 이상의 트랜젝션 관리자들을 함유하는 시스템 상에 데이터 d를 수정하는 트랜젝션들의 세트를 S라 하자. S는 다음 조건들이 만족되면 일관되게 수행된다:

(1) d의 모두 또는 일부를 액세스하는 S 내에 없는 어떤 요구 r1에 대해서, r1에 의해 액세스되는 d의 모든 부분들은, S 내의 어떤 트랜젝션에 의한 수정 전의 상태 또는 S 내의 모든 트랜젝션들에 의한 수정 후의 상태 중 어느 하나의 상태에 있다.

(2) r1과 동일하게 또는 r1 후에 시스템에 의해 r2가 수신되며 r1 및 r2가 모두 서브세트 d'를 액세스한다고 할 때, S 내에 있지 않은 요구들 r1 및 r2에 대해서,

(a) 만일 r1에 의해 액세스되는 d'의 버전이 S 내의 트랜젝션들에 의해 수정되면, r2에 의해 액세스되는 d'의 버전이 또한 S 내의 트랜젝션들에 의해 수정된다.

(b) 만일 r2에 의해 액세스되는 d'의 버전이 S 내의 트랜젝션들에 의해 수정되지 않으면, r1에 의해 액세스되는 d'의 버전도 또한 S내의 트랜젝션들에 의해 수정되지 않는다.

timestamp는 시스템에 의해 수신되는 트랜젝션 또는 획득된 잠금과 같은 이벤트들에 할당될 수 있는 속성이다. 선행 기술에서 타임 스탬프들을 구현하기 위한 일반적인 방법들은 이벤트들을 정돈하는 번호들 및 클럭 타임을 포함한다.

본 발명의 다른 특징은 하나 이상의 캐시들에 대한 일관성 있는 갱신들의 세트를 만드는 능력이다. 본 발명은 다음 성질들이 바람직한 하나 이상의 캐시 관리자들(3001)로 요구들(S)의 세트를 위해 사용된다.

(1) 시스템을 액세스하는 어떤 프로그램 p에 대해서, S는 자동으로 만들어져야만 한다. 즉, p는 S 내의 어떤 요구들이 충족되고 나머지들이 충족되지 않는 시스템에 대한 뷰(view)를 가질 수 없다.

(2) 동일 시각에 적절한 캐시 관리자들(3001)에 의해 수신된 어떤 2개의 요구들 r1 및 r2에 대해서, r1 및 r2는 S에 관하여 시스템의 동일한 뷰를 본다. 즉, r1 및 r2의 양자가 S 내의 요구들이 충족되기 전에 시스템의 뷰를 보거나, 또는 r1 및 r2의 양자가 S 내의 요구들이 충족된 후에 시스템의 뷰를 본다.

(3) r1이 캐시 관리자에 의해 수신된 후 r2가 캐시 관리자(3001)에 의해 수신된다고 할 때 임의의 2개의 요구들 r1 및 r2에 대해서, 만일 r1이 S 내의 요구들이 충족된 후의 시스템의 뷰를 가진다면, r2는 시스템의 동일한 뷰를 보아야만 한다. 만일 r2가 S내의 요구들이 충족되기 전에 시스템의 뷰를 본다면, r1은 동일 뷰를 보아야만 한다.

도 14는 하나 이상의 캐시들을 포함하는 시스템에 일관되게 요구들의 세트 S를 만들기 위한 로직의 예를 나타낸다. 바람직하게는 S 내의 각 요구는 하나의 캐시 관리자(3001)에게 전해진다(direct). S로부터의 요구를 수신하는 캐시 관리자들(C)의 세트는 하나 이상의 멤버들을 가질 수 있다.

도시된 바와 같이, 단계 4500에서, 요구들의 세트 S는 시스템에 의해 수신된다. 각 요구는 특정 캐시 관리자(3001)에게 전해진다.

단계 4505에서, 캐시 관리자들은 데이터를 잠근다. S로부터의 요구를 수신하는 각각의 캐시 관리자 j에 대해서, 캐시 관리자 j는 S내의 요구에 의해 수정되는 데이터를 위한 쓰기 잠금들 및 S 내의 요구에 의해 쓰여지지는 않으나 S내의 요구에 의해 읽혀지는 데이터를 위한 읽기 잠금들을 획득한다.

단계 4600에서, 시스템은 최종 잠금(last lock)을 획득하였던 때, last_lock_time을 결정한다. 만일 S로부터의 요구를 수신하는 캐시 관리자들(C)의 세트가 단지 하나의 멤버만을 가지면, 이 단계는 선행 기술을 사용하여 용이하게 구현될 수 있다. 만일 C가 복수의 멤버들을 가지면, last_lock_time은 도 42에서 설명되는 방식으로 결정된다.

단계 4510에서, 잠겨져 있는 데이터 상에서 대기중인 last_lock_time 전에 수신된 요구들이 수행된다. 단계 4520에서, S 내의 요구들이 수행된다. 단계 4530에서, 잠금들이 잠겨져 있는 데이터로부터 제거되어, 잠겨져 있는 데이터 상에서 대기중인 last_lock_time 후에 수신된 요구들이 수행되게 된다. 단계 4510, 4520, 4530은 순서대로 수행되어야만 한다.

도 41에 도시된 것의 변형 실시예는 S내의 요구에 의해 액세스되는 데이터를 요구들이 액세스하지 못하도록 하는 단일 잠금을 사용하는 것이다. 바람직한 실시예는 이러한 변형 방식보다 훨씬 고차원의 동시실행이 가능토록 한다.

도 42는 S로부터의 요구를 수신하는 캐시 관리자들의 세트 C가 복수의 멤버들을 갖는 경우 last_lock_time을 결정하기 위한 로직의 일 예를 나타낸다. 도시된 바와 같이, 단계 4600에서, cache mgr i로 표시되는 C의 각 멤버들은 단계 4505에서 최종 잠금을 획득한 시간 last_lock_time_i를 결정하고; 그리고 나서 cache mgr i는 코디네이터 프로그램(coordinator program)으로 알려진 프로그램으로 last_lock_time_i를 보낸다. 단계 4610에서, 코디네이터 프로그램은 C내의 모든 캐시 관리자들로부터 last_lock_time_i를 수신하고 last_lock_time을 그가 수신한 last_lock_time_i로 설정한다. 단계 4615에서, 코디네이터 프로그램은 C내의 모든 캐시 관리자들로 last_lock_time을 보낸다.

도 42에 도시된 예에 대한 변형은, C내의 각 cache mgr i로 하여금 코디네이터 프로그램으로 last_lock_time_i를 송신하는 대신에 단계 4600에서 C내의 다른 캐시 관리자들과 last_lock_time_i를 교환하도록 하는 것이다. 단계 4610에서, C내의 각 cache mgr i는 수신한 last_lock_time_i값들로부터 last_lock_time을 결정할 것이다. 단계 4615는 필요 없을 것이다. 바람직한 실시예는, 방금 설명한 변형예보다, C가 클 때 통신 및 비교가 덜 요구되므로 보다 확장가능(scaleable)하다.

이 기술분야의 숙련자는 트랜젝션 관리자들이 캐시 관리자들을 가질 필요가 없는 하나 이상의 트랜젝션 관리자들을 포함하는 다른 시스템들에서 일관성을 달성하기 위해서 본 발명을 용이하게 개조할 수 있을 것이다.

본 발명이 다양한 실시예들을 가지고 상세한 설명 방식으로 기재된 이상, 다양한 개선예들, 변형예들, 균등예들이 이 기술분야의 숙련자들에게 자명할 것이다. 따라서 상세한 설명은 제한으로서가 아니라 예로서 제공되었음이 이해되어야 한다. 본 발명의 적절한 범주는 클레임들에 의해 적절히 정의된다.

상술한 바와 같이, 본 발명은 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법을 제공하며, 또한 컴퓨터 시스템으로 하여금 하부 데이터 변경 후 시스템 내의 모든 오브젝트들로 갱신들을 전파하도록 하는 하부 데이터와 오브젝트들간의 의존성들을 특정하기 위한 방법을 제공한다. 그리하여, 시스템의 처리 성능을 향상시키는 효과를 갖는다.

Claims (63)

1. 하나 이상의 복합 오브젝트들을 저장하는 하나 이상의 캐시들을 포함하는 컴퓨터 시스템에서, 하부 데이터에 대한 변경들이 하나 이상의 복합 오브젝트들의 값들에 어떻게 영향을 줄 수 있는지를 결정하는 방법에 있어서, 하부 데이터의 적어도 일부를 식별하는-여기서, 하부 데이터는 캐시 가능하거나 또는 그렇지 않을 수 있음-단계와; 상기 하부 데이터의 적어도 일부에 대한 하나 이상의 데이터 의존성들을 갖는 하나 이상의 상기 복합 오브젝트들로 상기 하부 데이터의 적어도 일부를 맵핑하는 단계와; 시간에 따라 변할 수 있으며 그래프 오브젝트들간의 하나 이상의 의존성들을 나타내는 복수의 엣지들과 복수의 그래프 오브젝트들을 포함하는 오브젝트 의존성 그래프(G)를 유지하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
2. 제1항에 있어서, 복수의 컴퓨터들을 더 구비하는-여기서, 제1 캐시와 연관된 제1 세트의 컴퓨터들은 상기 맵핑하는 단계와 관련된 제2 세트의 컴퓨터들과 분리(disjoint)되어 있음-하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
3. 제1항에 있어서, 상기 맵핑하는 단계가, 서로 다른 스케줄들이 하부 데이터에 대한 서로 다른 변경들을 일으킬 수 있는 프로그램 스케줄링 동작들의 단계를 더 포함하는, 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
4. 제3항에 있어서, 상기 프로그램 스케줄링 동작들은 컴파일러, 런-타임 시스템, 또는 데이터베이스인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
5. 제1항에 있어서, 상기 맵핑하는 단계가, 적어도 하나의 복합 오브젝트로 상기 하부 데이터의 적어도 일부를 맵핑하기 위하여 상기 그래프를 사용하는 것을 포함하는, 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
6. 제1항에 있어서, 상기 엣지들에 웨이트들을 할당하는-여기서, 상기 웨이트들은 데이터 의존성들의 중요도에 상호 관련됨-단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
7. 제6항에 있어서, 적어도 하나의 엣지의 웨이트는 그것이 할당된 후 변하지 않는, 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
8. 제6항에 있어서,

   (1) 그래프 오브젝트 o1의 2개의 버전들 o1_v1 및 o1_v2가 존재하고,

   (2) 상기 오브젝트 의존성 그래프(G)가 o1에서 종료하고 할당된 웨이트를 갖는 적어도 하나의 엣지(o2, o1)를 포함하며,

   상기 o1에서 종료하고 세트 S를 포함하는 하나 이상의 엣지들(o2, o1)에 대해서, o1_v1과 일관성 있는 상기 오브젝트(들) o2의 버전 번호와 o1_v2와 일관성 있는 상기 오브젝트(들) o2의 제2 버전 번호를 유지하는 단계와; 상기 그래프 오브젝트 o2의 동일 버전이 상기 버전들 o1_v1 및 o1_v2와 일관성이 있게 되는 상기 세트 S내에 엣지들(o2, o1)의 웨이트들의 합 및 상기 세트 S내의 o1에서 종료하는 모든 엣지들의 웨이트들의 합에 기초하여 o1_v1 및 o1_v2가 얼마큼 유사한지를 결정하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
9. 제8항에 있어서, 상기 2개의 버전들이 얼마나 유사한지를 결정하는 상기 단계가, 상기 그래프 오브젝트 o2의 동일 버전이 상기 버전들 o1_v1 및 o1_v2와 일관성이 있도록 상기 세트 S 내의 엣지들(o2, o1)의 웨이트들의 합을, 상기 세트 S 내의 o1에서 종료하는 모든 엣지들의 웨이트들의 합으로 나누는 단계는 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
10. 제1항에 있어서, 상기 맵핑하는 단계가, 상기 하부 데이터의 적어도 일부에 대한 변경들이 있는지 또는 어떻게 변경하는지를 결정하기 위하여 상기 하부 데이터의 적어도 일부에서의 변경들에 의해 하나 이상의 복합 오브젝트들이 어떻게 영향을 받을 수 있는지에 관한 정보를 사용하는 단계를 더 포함하는, 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
11. 제1항에 있어서, 상기 맵핑하는 단계를 구현하는 프로그램은 복수의 프로세스들; 복수의 스레드들; 상기 하나 이상의 캐시들을 위한 저장소를 관리하는 하나 이상의 장기-실행 프로세스들 또는 스레드들 중에서 하나 이상을 발생하는, 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
12. 제1항에 있어서, 상기 맵핑하는 단계가 상기 하부 데이터의 적어도 일부에 대한 변경을 식별하는 단계; 및 상기 하부 데이터의 적어도 일부에 대한 변경을 식별하는 것에 응답하여, 어떻게 하나 이상의 복합 오브젝트들이 영향을 받는지를 식별하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
13. 제11항에 있어서, 상기 맵핑하는 단계를 구현하는 프로그램이 적어도 하나의 장기-실행 프로세스를 발생하며, 애플리케이션 프로그램이 상기 하부 데이터의 적어도 일부에 대한 변경을 식별하는 단계와; 상기 애플리케이션 프로그램이 상기 맵핑하는 단계를 구현하는 상기 프로그램으로 상기 하부 데이터의 적어도 일부에 대한 식별된 변경을 통신하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
14. 제1항에 있어서, 상기 하부 데이터의 적어도 일부에 대한 변경들의 결과로서 캐시 내에 저장된 복합 오브젝트들의 버전이 매우 낡게 되었을 것이라고 결정하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
15. 제14항에 있어서, 상기 캐시로부터 오브젝트의 매우 낡은 버전을 삭제하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
16. 제14항에 있어서, 오브젝트의 상기 버전이 현행하지 않을 때마다 그것이 매우 낡은 것으로 간주되는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
17. 제14항에 있어서, 오브젝트(o1_v1)의 버전이 매우 낡게 되었을 것이라고 결정하는 상기 단계는: 시간에 걸쳐서 변할 수 있으며 복수의 그래프 오브젝트들(o1, ..., on)과 그래프 오브젝트들 간에 하나 이상의 데이터 의존성들을 표시하는 엣지들을 포함하는 오브젝트 의존성 그래프(G)을 유지하는 단계와; o1_v1이 o2의 현행 버전과 일관성이 없는 엣지들(o2, o1)의 수에 기초하여 상기 o1_v1이 매우 낡았음을 결정하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
18. 제14항에 있어서, 오브젝트의 매우 낡은 버전을 보다 최근 버전으로 교체하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
19. 제18항에 있어서, 상기 보다 최근 버전은 상기 오브젝트의 현행 버전인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
20. 제14항에 있어서, 캐시 내에 저장된 오브젝트 o1의 버전 o1_v1이 매우 낡게 되었음을 결정하는 상기 단계가: 시간에 걸쳐서 변할 수 있으며 복수의 그래프 오브젝트들과 그래프 오브젝트들간의 하나 이상의 데이터 의존성을 표시하는 엣지들을 포함하는 오브젝트 의존성 그래프(G)를 유지하는 단계와; 상기 o1에서 종료하는 하나 이상의 엣지들에 상응하는 상기 o1_v1을 위한 weight-act 필드들을 초기화하고 유지하는 단계와; 오브젝트 o2에서 상기 오브젝트 o1로 엣지가 나가고 o1_v1이 weight_act 필드를 갖도록 하는 그래프 오브젝트 o2의 현행 버전에 대한 하나 이상의 변경들에 대해서, 상기 엣지에 상응하는 상기 weight_act 필드를 감소시키는 단계와; 상기 o1_v1이 매우 낡게 되었는지를 그의 weight_act 필드들에 기초하여 결정하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
21. 제20항에 있어서, 상기 o1_v1을 위한 임계 웨이트를 유지하는 단계를 더 포함하고, 상기 o1_v1이 매우 낡게 되었는지를 그의 weight_act 필드들에 기초하여 결정하는 상기 단계가, 상기 o1_v1을 위한 상기 weight_act 필드들의 합을 상기 임계 웨이트와 비교하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
22. 제20항에 있어서, 상기 오브젝트 의존성 그래프의 상기 엣지들에 웨이트들을 할당하는-여기서, 상기 웨이트들은 데이터 의존성들의 중요도에 관련됨-단계와; 상기 오브젝트 의존성 그래프에서 상응하는 엣지의 하나 이상의 웨이트들로 상기 o1_v1을 위한 하나 이상의 weight_act 필드들을 초기화하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
23. 제20항에 있어서, o2의 상기 현행 버전이 갱신될 때마다, 상기 오브젝트 의존성 그래프에서 상기 o2에서 상기 o1로의 엣지에 상응하며 가능한 소정 최소값보다 큰 상기 weight_act 필드를, 상기 가능한 소정 최소값으로 설정하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
24. 제1항에 있어서, 상기 하나 이상의 캐시들이: 복수의 버전 캐시, 단일 버전 캐시, 현행 버전 캐시 중에서 하나 이상을 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
25. 제24항에 있어서, 상기 하나 이상의 캐시들이 적어도 하나의 단일 버전 캐시 c1을 포함하고, 상기 오브젝트들 o1의 적어도 하나에 대해서, o1 및 o2 모두가 c1내에 함유될 때마다 일관성이 있어야만 되도록 하는 다른 오브젝트들 o2의 일관성 세트를 유지하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
26. 제25항에 있어서, 상기 o1 및 o2가 모두 cl내에 있으면 상기 o1과 상기 o2가 일관성이 있다고 보증하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
27. 제26항에 있어서, 상기 단일 버전 캐시에 상기 오브젝트 o1의 현행 버전을 추가하고, 가능하게는 상기 오브젝트 o1의 이전 버전을 교체하는 단계와; 오브젝트(들) o2의 비현행 버전 o2_v가 상기 캐시 c1 내에 함유되고 상기 o2_v가 상기 o1의 현행 버전이 생성되기 전에 생성되도록, 상기 o1의 일관성 세트에서 하나 이상의 오브젝트들 o2를 식별하는 단계와; 상기 캐시 c1로부터 상기 o2_v를 제거하거나 상기 오브젝트(들) o2의 보다 최근 버전으로 o2_v를 교체하는 단계와; 상기 오브젝트(들) o2를 위한 일관성 세트에서의 오브젝트들에, 하나 이상의 오브젝트들을 식별하는 상기 단계와 상기 캐시 c1로부터 상기 o2_v를 제거하거나 상기 오브젝트(들)의 보다 최근 버전으로 o2_v를 교체하는 단계를, 반복적으로 적용시키는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
28. 제25항에 있어서, 상기 단일 버전 캐시에 오브젝트 o1의 버전을 추가하는지의 여부를 결정하기 위하여 오브젝트 o1을 위한 상기 일관성 세트를 사용하며, 가능하게는 상기 오브젝트 o1의 이전 버전을 교체하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
29. 제26항에 있어서, 단일 버전 캐시 c1에서의 복수의 오브젝트들 o1, ..., on에 대해서, 오브젝트 oi를 위한 일관성 세트에 의해 부여되는 모든 제한들이 상기 oi가 갱신될 때 충족되었는지를 확인하지 않고 대신에 obj1의 일관성 없는 버전이 c1내에 존재하는 상기 oi를 위한 일관성 세트로부터의 오브젝트들 obj1을 일관성 스택에 추가하여 c1 내에 서로 다른 버전으로 오브젝트 oi 각각을 교체하는 단계와; c1 내의 모든 오브젝트들 o1, ..., on이 현행 버전들로 교체된 후, 상기 일관성 스텍 상의 모든 오브젝트들을 주사(traverse)하여, 일관성 없는 버전이 c1에 존재하게 되는 그런 오브젝트 obj1 각각에 대해서, c1으로부터 그것을 제거하거나 일관성 있는 버전으로 그것을 교체하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
30. 제1항에 있어서, 상기 G는 단순 의존성 그래프, 멀티그래프 중의 하나인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
31. 제30항에 있어서, 상기 G는 적합한 최고 노드들(maximal nodes)이 복합 오브젝트들이고 적합한 리프 노드들이 오브젝트들이 아닌 하부 데이터인 단순 의존성 그래프인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
32. 제31항에 있어서, 상기 오브젝트 의존성 그래프를 유지하는 단계는: 적어도 하나의 적합한 리프 노드 v를 위한 발신 인접도 리스트(outgoing adjacency list)를 유지하는 단계와; 적어도 하나의 적합한 최고 노드 w를 위한 인입 인접도 리스트를 유지하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
33. 제32항에 있어서, 발신 인접도 리스트들 및 인입 인접도 리스트들 중 하나를 해시 테이블을 통해서 액세스하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
34. 제32항에 있어서, 오브젝트 의존성 그래프를 유지하는 상기 단계가: 적합한 리프 노드 변경들에 의해 표시될 수 있는 어떤 데이터 d를 초기 변경된 데이터가 포함할 때, d에 상응하는 상기 발신 인접도 리스트를 검색하는 단계와; 만일 상기 발신 인접도 리스트가 발견되면, 어느 복합 오브젝트들이 영향을 받는지를 결정하기 위해 상기 리스트를 검사하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
35. 제32항에 있어서, 상기 오브젝트 의존성 그래프로부터 적어도 하나의 적합한 최고 노드 w를 삭제하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
36. 제35항에 있어서, 상기 오브젝트 의존성 그래프로부터 적어도 하나의 적합한 최고 노드 w를 삭제하는 상기 단계가: 상기 w를 위한 상기 인입 인접도 리스트 상에 적어도 하나의 적합한 리프 노드를 위한 상기 발신 인접도 리스트로부터 상기 w를 삭제하는 단계와; 상기 w를 위한 상기 인입 인접도 리스트를 삭제하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
37. 제33항에 있어서, 상기 오브젝트 의존성 그래프로부터 적어도 하나의 적합한 리프 노드 v를 삭제하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
38. 제37항에 있어서, 상기 오브젝트 의존성 그래프로부터 적어도 하나의 적합한 리프 노드 v를 삭제하는 상기 단계가: v를 위한 상기 발신 인접도 리스트 상에 하나 이상의 적합한 최고 노드들을 위한 상기 인입 인접도 리스트로부터 v를 삭제하는 단계와; 상기 v를 위한 상기 발신 인접도 리스트를 삭제하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
39. 제1항에 있어서, 그래프 오브젝트 r은 단일(SRO) 또는 복수의(MRO) 레코드들 중의 하나를 표시할 수 있는 연관된 관계 특정자를 갖는 관계 오브젝트(RO)이고 상기 오브젝트 의존성 그래프를 유지하는 단계가:

    (a) 상기 r을 위한 상기 관계 특정자를 저장하는 단계와;

    (b) 만일 하나 이상의 그래프 오브젝트들이 상기 r을 포함하면, 상기 r로부터의 하나 이상의 의존성들을 상기 r을 포함하는 하나 이상의 그래프 오브젝트들에 추가하는 단계와;

    (c) 만일 상기 r이 하나 이상의 그래프 오브젝트들을 포함하면, 상기 r에 의해 포함되는 상기 하나 이상의 그래프 오브젝트들로부터 상기 r로의 하나 이상의 의존성들을 추가하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
40. 제39항에 있어서, 상기 엣지들로 웨이트들을 할당하는-여기서, 상기 웨이트들은 데이터 의존성들의 중요도에 상호관련됨-단계를 더 포함하고, 상기 단계들 (b) 및 (c) 중의 하나는, 상기 r2에 의해 함유되는 상기 r1의 레코드들의 비율(percentage); 상기 레코드들의 상대적인 중요도 중의 어느 하나 또는 양쪽 모두에 따라서, RO 노드 r2를 함유하는 RO 노드 r1에 상응하는 상기 의존성들의 적어도 하나의 웨이트를 결정하는 단계를 포함하는, 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
41. 제39항에 있어서, (d) 상기 r2내에 또한 함유된 상기 r내의 레코드들의 비율과, 상기 r2내에 또한 포함된 상기 r내의 상기 레코드들의 상대적인 중요도 중의 어느 하나 또는 양쪽 모두에 근거하여 메트릭(metric)을 사용하여 상기 r로부터 또 다른 RO r2로의 하나 이상의 의존성들을 부가하는-여기서, 상기 또 다른 RO r2는 상기 r에 포함되지 않음-단계와;

    (e) 상기 r에 또한 포함된 상기 r3내의 레코드들의 비율과, 상기 r에 또한 함유된 상기 r3내의 레코드들의 상대적인 중요도의 어느 하나 또는 양쪽 모두에 근거하여 메트릭을 사용하여 또 다른 RO r3으로부터 r로의 하나 이상의 의존성들을 추가하는-여기서, 상기 r은 상기 r3 내에 포함되지 않음-단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
42. 제41항에 있어서, 상기 엣지들에 웨이트들을 할당하는-여기서, 상기 웨이트들은 데이터 의존성들의 중요도에 상호관련됨-단계와; 상기 메트릭을 사용하여 단계 (d) 및 단계 (e) 중의 하나 또는 양쪽 모두에서 추가된 상기 하나 이상의 의존성들의 웨이트를 계산하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
43. 제39항에 있어서, 상기 r은 새로이 생성된 노드, 수정되고 있는 현존 노드, SRO 노드, MRO 노드 중의 어느 하나인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
44. 제40항에 있어서, 공통 레코드를 갖는 RO들의 쌍들이 동일 관계 이름을 소유할 가능성이 매우 높게 되도록 하나 이상의 관계 특정자들이 관계 이름들을 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
45. 제44항에 있어서, 관계 이름들, 상기 관계 이름들과 결부되는 밸런스된 트리 중의 하나를 사용하여 RO들을 분리하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
46. 제39항에 있어서, 상기 하부 데이터의 적어도 일부를 식별하는 상기 단계가: 관계 특정자를 식별하는 단계와; 상기 관계 특정자를 가지고 공통으로 하나 이상의 레코드를 갖는 상기 오브젝트 의존성 그래프에 하나 이상의 RO들을 위치시키는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
47. 제1항에 있어서, 상기 맵핑하는 단계가: 상기 하부 데이터의 상기 적어도 일부에 상응하는 상기 오브젝트 의존성 그래프에서 하나 이상의 노드들의 세트(update_set)를 방문하는 단계와; 상기 update_set로부터 도달 가능한 노드들을 방문하기 위하여 상기 오브젝트 의존성 그래프에서 상기 엣지들을 주사(traverse)하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
48. 제47항에 있어서, 상기 주사하는 단계가 깊이-우선 방식과 넓이-우선 방식 중의 하나로 상기 오브젝트 의존성 그래프를 주사하는 단계인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
49. 제47항에 있어서, 각각의 오브젝트 의존성 그래프 주사(object dependence graph traversal)를 고유하게 식별하는 타임스탬프를 유지하는 단계와; 주사동안 처음으로 꼭지점(vertex)을 방문할 때마다 상기 오브젝트 의존성 그래프의 꼭지점에 타임스탬프를 저장하는 단계와; 상기 꼭지점에서의 상기 타임스탬프와 상기 현재 주사를 위한 상기 타임스탬프를 비교함으로써 현재 주사동안 꼭지점이 방문되었는지를 결정하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
50. 제49항에 있어서, 각각의 새로운 그래프 주사를 위한 타임 스탬프를 증가시키는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
51. 제1항에 있어서, 그래프 오브젝트 o1의 2개의 버전들 o1_v1 및 o1_v2 이 존재하고, 상기 오브젝트 의존성 그래프(G)가 o1에서 종료하는 적어도 하나의 엣지(o2, o1)를 함유하며, 상기 o1에서 종료하고 세트 S를 포함하는 하나 이상의 엣지들(o2, o1)에 대해서, o1_v1에 일관되는 상기 오브젝트(들) o2의 버전 번호와 o1_v2와 일관성 있는 상기 오브젝트(들) o2의 제2 버전 번호를 유지하는 단계와; 그래프 오브젝트 o2의 동일 버전이 상기 버전들 o1_v1 및 o1_v2와 일관되는 상기 세트 S 내의 엣지들(o2, o1)의 수와 상기 세트 S에서 종료하는 모든 엣지들의 수에 근거하여 o1_v1 및 o1_v2가 얼마큼 유사한지를 결정하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
52. 제51항에 있어서, o1_v1 및 o1_v2가 얼마큼 유사한지를 결정하는 상기 단계가: 그래프 오브젝트 o2의 동일 버전이 상기 버전들 o1_v1 및 o1_v2와 일치하게 되는 상기 세트 S내의 엣지들(o2, o1)의 수를 상기 세트 S 내의 o1에서 종료하는 모든 엣지들의 수로 나누는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
53. 제1항에 있어서, 적어도 얼마간의 오브젝트들이 웹 서류들이고 적어도 얼마간의 하부 데이터가 하나 이상의 데이터베이스들의 일부인 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
54. 제14항에 있어서, 캐시 내에 저장된 복합 오브젝트 o1의 버전이 매우 낡게 되었는지를 결정하는 상기 단계가 상기 o1의 버전이 상기 o2의 현행 버전에 일치하지 않게 되는 엣지들(o2, o1)의 수를 결정하는 단계를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
55. 제54항에 있어서, 캐시 내에 저장된 복합 오브젝트 o1의 버전이 매우 낡게 되었는지를 결정하는 상기 단계가 상기 o1에서 종료하는 엣지들의 총 수에 근거하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
56. 제1항에 있어서, s_update 내의 하나 이상의 오브젝트 상에서, 상기 오브젝트 의존성 그래프에 의해 직접적으로 또는 추이적(transitively)으로 특정된, 의존성들을 갖는 적어도 하나의 다른 그래프 오브젝트가 어떻게 영향을 받는지를 결정하기 위하여, 상기 오브젝트 의존성 그래프와 함께, 하나 이상의 그래프 오브젝트들의 세트 s_update가 상기 하부 데이터에 대한 변경들에 의해 어떻게 영향을 받는지에 관한 정보를 사용하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
57. 제29항에 있어서, 링크된 리스트 상에서 상기 오브젝트들에 대한 레퍼런스들을 저장함으로써 상기 일관성 스택을 구현하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
58. 제29항에 있어서, 상기 일관성 스택을 구현하기 위해 하나 이상의 밸런스된 트리들을 사용하는 단계와; 적어도 하나의 오브젝트 obj1에 대해서, 상기 일관성 스택에 상기 obj1에 대한 레퍼런스를 추가하기 전에 상기 obj1의 레퍼런스가 상기 일관성 스택 상에 아직 포함되지 않음을 확인하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
59. 제26항에 있어서, 상기 일관성 세트(들)가 하나 이상의 링크된 리스트들을 사용하여 구현되는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
60. 하나 이상의 오브젝트들의 현행 값에 영향을 주는 하부 데이터를 저장하는 하나 이상의 원격 데이터 소스들과, 하나 이상의 복합 오브젝트들을 저장하는 하나 이상의 캐시들을 포함하는 컴퓨터 시스템에서, 시간에 걸쳐서 변할 수 있고 복수의 그래프 오브젝트들과 상기 그래프 오브젝트들간의 하나 이상의 데이터 의존성들을 표시하는 엣지들을 포함하는 오브젝트 의존성 그래프를 유지하는 단계와; 상기 하부 데이터의 적어도 일부가 변경될 때를 인식하는 단계와; 변경된 상기 하부 데이터의 적어도 일부에 관한 정보, 변경된 상기 하부 데이터의 결과로서 변경된 값을 갖는 적어도 하나의 오브젝트의 식별을 포함하는 정보, 변경된 상기 하부 데이터의 결과로서 변경된 값을 갖는 적어도 하나의 오브젝트의 식별이 결정되도록 허여하는 정보 중 하나 이상을, 캐시로 통신하는 단계와; 상기 통신하는 단계에 응답하여, 상기 캐시로부터 오브젝트를 제거하거나, 상기 캐시 내의 오브젝트의 새로운 버전을 갱신하는 단계를 포함하는 방법.
61. 제12항에 있어서, 상기 하부 데이터의 적어도 일부는 하나 이상의 원격 데이터 소스들에 저장되고, 변경된 상기 하부 데이터의 적어도 일부에 관한 정보, 변경된 상기 하부 데이터의 결과에 따라 변경된 값을 갖는 적어도 하나의 오브젝트의 식별을 포함하는 정보, 변경된 상기 하부 데이터의 결과에 따라 변경된 값을 갖는 적어도 하나의 오브젝트의 식별자가 결정되도록 허여하는 정보 중 하나 이상을 캐시로 통신하는 단계와; 상기 통신하는 단계에 응답하여, 상기 캐시로부터 오브젝트를 제거하거나 상기 캐시 내에 오브젝트의 새로운 버전을 갱신하는 단계를 더 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.
62. 제1-2, 5-12, 13, 18, 21-24, 26-30, 47, 48, 50 중의 어느 한 항에 따라, 하부 데이터에 대한 변경들이 하나 이상의 복합 오브젝트들의 값들에 어떻게 영향을 줄 수 있는지를 결정하기 위한 방법 단계들을 수행하기 위해서 머신에 의해 실행가능한 명령어들(instructions)의 프로그램을 유형적으로 구체화한, 머신에 의해 읽을 수 있는 프로그램 저장 장치.
63. 하나 이상의 복합 오브젝트들을 저장하는 하나 이상의 캐시들을 포함하는 컴퓨터 시스템에서, 하부 데이터에 대한 변경들이 하나 이상의 복합 오브젝트들의 값들에 어떻게 영향을 줄 수 있는지를 결정하는 방법에 있어서, 상기 하부 데이터의 적어도 일부를 식별하는-여기서, 상기 하부 데이터는 캐시 가능하거나 또는 그렇지 않을 수 있음-단계와; 상기 하부 데이터의 적어도 일부에 대한 하나 이상의 데이터 의존성들을 갖는 하나 이상의 상기 복합 오브젝트들로 상기 하부 데이터의 적어도 일부를 맵핑하는 단계-여기서, 적어도 일부의 오브젝트들은 웹 도큐먼트들이며, 적어도 일부의 상기 하부 데이터들은 하나 이상의 데이터 베이스의 일부임-를 포함하는 하부 데이터에 대한 변경이 오브젝트들에 어떻게 영향을 주는지를 결정하는 방법.