KR20090035527A

KR20090035527A - 영속성 관리 방법, 장치 및 컴퓨터 판독 가능 매체

Info

Publication number: KR20090035527A
Application number: KR1020097000984A
Authority: KR
Inventors: 스테판 제임스 토드
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2006-07-01
Filing date: 2007-06-26
Publication date: 2009-04-09
Also published as: CN101490651B; TW200823760A; GB0613192D0; TWI430176B; KR101054994B1; JP5084827B2; US20160357619A1; US20100017441A1; EP2038746A1; EP2038746B1; JP2009541882A; US9495229B2; US20200133750A1; CN101490651A; US10528405B2; WO2008003617A1

Abstract

메시징 시스템, 데이터베이스 시스템 또는 파일 시스템과 같은 데이터 처리 시스템내에서 영속성을 관리하기 위한 방법, 장치 및 컴퓨터 프로그램을 설명한다. 영속성 관리 방법은 영속성 동작을 완전히 사전 정의하는 대신에, 영구 저장소에 저장하는 비용 및/또는 이익과 연관된 적어도 하나의 기준의 지연된 평가(230, 330, 430)를 포함한다. 평가는 디스크 기록이 막 수행될 때(230, 340, 440), 또는 데이터 업데이트 처리 도중 다양한 시점에서, 데이터 처리 망내의 다양한 지점에서 수행될 수 있다. 메시징 방법에서 영속성 관리 방법은 영구 저장소에 저장하는 비용 및/또는 이익의 동적 평가(230, 330, 430)를 포함하는데, 이 평가는, 그 메시지가 원시 개체에 의해 생성되어 전송된 이후에 메시징 네트워크내의 다양한 지점에서 수행된다. 영속성 관리 방법은 메시지 관련 데이터 및/또는 로그 레코드가 영구 저장소로의 저장을 필요로하는 지를 영구 저장소로 저장하는 비용 및/또는 이익에 따라 판정하는 단계를 포함한다. 영속 이익은 메시지 값(400)을 참조하여 판정될 수도 있다.

영속성, 데이터 처리

Description

영속성 관리 방법, 장치 및 컴퓨터 판독 가능 매체{METHODS, APPARATUS AND COMPUTER PROGRAMS FOR MANAGING PERSISTENCE}

본 발명은 메시징 시스템, 파일 시스템 및 데이터베이스와 같은 데이터 처리 시스템에서의 영속성 관리(management of persistence)에 관한 것이다.

몇몇 공지된 메시지 시스템들은 메시지 상태 정보와 메시지들이 영구 저장소(persistent storage; 즉, 디스크 저장소와 같은 비휘발성 저장소)내의 로그(logs) 및 메시지 큐 데이터 파일들에 저장되는 '영속적(persistent)' 메시징을 제공한다. 영속적으로 저장되는 메시지는 메시징 시스템의 고장 및 재시작 후에도 잔존(survive)할 수 있다. 디스크 고장 외의 고장에 대응하여, 메시지 상태 정보와 메시지들은 로그 데이터(logged data) 및 영구 저장 큐로부터 재생될 수 있다. 영속 메시지와 상태 정보의 복구능력은 단 한번의 메시지 전달을 보장하는 데 있어서 중요한 요인이다.

예를 들어, 메시징 관리자는 메시지에 관한 동작이 성공적으로 수행되었음을 애플리케이션 프로그램에게 확인시키기 이전에 디스크 저장소에 영속 메시지를 저장할 수 있다. 기존 메시징 네트워크에서, 메시지-전송 애플리케이션 프로그램은 아웃고잉 메시지를 큐에 위치시키기 위해 API 호출을 통하여 'put_message' 명령어를 발행한다. 로컬 메시징 관리자 프로그램은 이 큐를 관리하고 다른 애플리케이션 프로그램 또는 분산 메시징 네트워크내의 다른 메시징 관리자들과 통신하여 그 메시지를 타겟 수신자에게 전달한다. 영속적 메시징 시스템에서, 로컬 메시징 관리자는 전송자 애플리케이션에게 'put_message' 동작이 성공적으로 완료했음을 확인시키기 이전에 그 메시지를 영구 저장소에 저장한다. 영속 메시지 또는 메시지 관련 데이터는 그 메시지를 그 목적지(일 실시예에서, 그 메시지는 현재의 싱크포인트-관리자(syncpoint-manager)가 제어하는 '작업 단위(unit of work)'의 외부임)로 전달하기 위해 수행되는 모든 'put_message' 및 'get_messge'에 대하여 디스크에 기록될 수 있고, 또는 이 메시지는 현재의 작업 단위가 처리되는 때에만 로그될 수 있다. 분산형 작업 단위에 있어서, 메시지 전송 중 다수의 지점에서 로그들을 기록하는 것을 방지할 수도 있지만, '영속적'으로 식별되는 메시지는 사전 정의된 지점에 영구 저장소에 기록될 것이다.

이와 반대로, '비영속(non-persistent)' 메시지는 디스크에 저장되지 않아서, 메시징 관리자가 조작자 명령에 의해 중단되는 경우뿐만 아니라 메시징 관리자가 고장나거나 재시작해야하는 경우 폐기가 된다. 영속적 메시징은 재생의 기간 및 메시지 전달 보장에 있어서 큰 이점을 제공하지만, 여기에는 실행 비용이 따른다. 각각의'put_messge' 및 'get_message' 동작에 대해서 디스크에 기록을 하는 것은 메시지 처리율은 감소시키고 애플리케이션 응답 시간은 증가시켜 일부 메시지들은 비영속적으로 처리해야 한다는 정당한 이유가 생기게 된다.

메시지 전달 보장과 성능간의 트레이드오프로 인해, IBM사의 WebSphere MQ 계열 제품들은 메시지의 선택적 속성으로서 "영속적" 또는 "비영속적"을 설정하는 것을 지원하고, 영속적 메시징의 성능을 향상시키기 위해 상당한 작업이 수행되었다(WebSphere 및 IBM은 IBM사의 상표임). 고성능 디스크 저장소, 고장의 부재시 성능을 최적화하는 커밋 처리 방법(commit processin techniques) 및 고장을 처리하기 위한 효율적인 복구 방법을 이용함으로써 성능이 향상되었다. 예를 들어, 1994년 3월 23일에 출원되었으며 IBM사가 특허권자인 미국 특허 제 5,452,430호에는, 단일의 메시지 큐내의 별도의 페이지 세트들에 영속 데이터 및 비영속 데이터를 저장함으로써 시스템 고장으로부터의 복귀 과정 중의 지연을 감소시키기 위한 영속 및 비영속 메시지 처리 방법이 개시되어 있다. 1994년 IEEE Data Engineering Bulletin, 17(1), 22-28쪽에는 C.Mohan 및 D. Dievendorff의 "Recent Work on Distrubuted Commit Protocls, and Recoverable Messaging and Queing"에는 분산형 커밋 프로토콜, 복구 가능한 메시징 및 큐잉의 영역의 개선안을 개시하고 있다.

그러나, 전형적인 메시징 시스템은 비교적 비융통적인 영속성 규정을 갖는다. 일 예로서는, 메시징 시스템 사용자에게 서로 다르게 정의된 시스템 상태들에 대해 서로 다른 영속성 정책을 지정할 수 있게 하는 것이다. 이러한 메시징 시스템에서는 사용자가 영속성 제어를 더 세분화할 수 있다는 것에서는 이익을 얻을 수는 있으나, 영속성 동작은 영속성 정책이 지정될 때에 고정이 된다.

메시지 영속성이 원하는 특성으로서 지정되었으면, 전형적인 메시징 시스템 에서는 메시지 무결성(integrity)을 보장하는 데에 그 자원들을 너무 많이 이용한다. 많은 애플리케이션에서, 개별 메시지들 중 대부분이 이러한 이용을 하는 데에는 너무 낮은 값을 갖지만, 값을 달리하는 메시지들간에 구별을 하거나, 또는 영속시키는 비용 또는 영속시키지 않는 경우 이와 관련된 리스크를 고려할 수 없다.

메시징 시스템에 더하여, 성능과 영속성간의 트레이드오프는 데이터베이스, 파일 시스템 및 다른 영속성 시스템에도 적용된다. 데이터 시스템에서는, 데이터가 통상 영구적으로 저장되지만, 영구 저장소로의 기록을 강제하지 않으며 특정 테이블을 저장하는 것도 공지되어 있다. 따라서, 쿼리/구조 특성의 이익을 낮은 오버헤드 저장 방법으로 얻을 수 있게 된다. 이는 "경량의(lightweight)" 데이터베이스 솔루션이 융통성 있는 영속성 관리 방법을 더 필요로 할 것 같다는 의미이다. 파일 시스템은 신뢰성 있는 데이터에 대한 사용 ― 예를 들어 파일 시스템내에 XML 파일로 애플리케이션 서버에 대한 구성 데이터(configuration data)를 유지함 ― 이 증가된다. 트랜잭션 파일 시스템에 대한 요구가 증가해 오고 있으나, 현재의 솔루션들은 융통적인 영속성 제어를 제공하지 않는다.

본 발명의 제1 측면은 영구 저장소에 저장하는 비용; 또는 영구 저장소에 저장하지 않는 경우 이와 관련된 리스크;와 관련된 적어도 하나의 기준에 따라 데이터 처리 시스템내에서 데이터의 영속성을 관리하기 위한 방법을 제공한다. 평가는 디스크 기록이 막 수행되려는 시점에 수행될 수 있으나, 데이터 업데이트 처리 도중의 다양한 시점에 그리고 데이터 처리망내의 다양한 지점에서 수행될 수도 있다.

본 발명은 메시징 시스템, 데이터 시스템, 파일 시스템 그리고 영구 저장소에 데이터를 저장하는 기타 데이터 처리 시스템으로 구현될 수 있다. 본 발명의 제1 실시예는 메시징 시스템내에서 적어도 하나의 기준의 동적 평가에 따라 메시지의 영속성을 관리하는 방법을 제공한다. 평가는 메시지가 생성되어서 원시 개체에 의해 전송된 이후에 동적으로 수행된다. 이러한 방법은 메시지 데이터 및/또는 그 메시지와 관련된 로그 기록들에 의해서, 자원 비용 또는 성능 비용 및/또는 영구 저장소에 저장하는 이익에 따라, 영구 저장소로의 저장이 필요한 지 판정하는 것을 포함한다.

이러한 면에서, 특정한 메시지에 대해서 영속성 판정하는 경우 고려되는 영구 저장소로의 저장하는("영속시키는(persisting)") 이익은 바람직하게, 그 특정 메시지의 값, 그리고 메시지 관련 데이터를 손실하거나 중복하게 될 리스크를 고려한다. 예를 들어, 메시지의 손실 '비용'은 개별 메시지의 중요도를 기초로 할 수 있고, 또는 그 메시징 시스템이 소정의 서비스 요건을 충족시킬 수 있는 능력을 기초로 할 수 있다. 영속시키는 '비용'은 바람직하게는 영구 저장소에 기록하는 경우의 성능 효과를 고려하며, 바람직하게는 현재의 가용 자원과 자원 제한, 예를 들어, 내부 영속 큐(internal persistence queue)에의 경쟁 상황을 참조한다.

영구 저장소로 저장할 지에 대한 판정은 메시지가 전송 애플리케이션으로부터 로컬 메시징 관리자를 통해 또는 메시징 시스템들의 망을 통해 타켓 수신 애플리케이션으로 전달될 때 다양한 지점에서 수행될 수 있다. 예를 들어, 전송 애플리케이션은 로컬 메시징 관리자가 만든 큐에 메시지를 위치시키기 위하여 'put_message' 명령어를 발행할 수 있고, 로컬 메시징 관리자(또는 '큐 관리자')는 그 메시지를 망내의 다음 메시징 관리자에게 등으로, 그 메시지가 타겟 애플리케이션의 로컬 메시징 관리자에게 도달할 때까지 전달할 수 있다. 그러면 타겟 애플리케이션은 자신의 로컬 메시징 관리자가 유지하는 메시지 큐에서 그 메시지를 검색한다. 본 발명에 따라, 영속성 판정은 이러한 통신 경로내의 각 메시징 관리자에서 수행될 수 있으며, 그 메시지는 메시징 관리자 각각에게 영향을 미치는 동적 특성을 기초로 하여 하나의 메시징 관리자에서 영속될 수 있으며, 또 다른 메시징 관리자에서는 영속되지 않는다.

영구 저장소로 기록할 지에 대한 판정이 이와 같이 연기형(deferred)으로 그리고 잠재적으로 반복되는 것은 메시지가 생성되었을 때 또는 처음으로 전송될 때에 영속성 동작을 정의하는 종래의 메시징 시스템들과는 상당히 차이가 있다.

예를 들어, 메시지가 제1 큐 관리자 QM1로부터 제2 큐 관리자 QM2로 신속히 이동되는 경우, 그 메시지는 QM1에서는 영구적으로 저장될 필요가 없을 수도 있다. 최종 사용자 애플리케이션이 느리거나 비활성화 상태여서 메시지가 QM2에서 소정 기간 대기하는 경우에 그 메시지는 QM2에서 영속될 수도 있다. '전달자(mover)'(메시지 채널 에이전트라고도 함)는 QM1 상의 전송 큐로부터 QM2 큐로 메시지를 이동시키는 역할을 하는 메시지 큐 관리자이다. QM1이 만든 큐에 메시지가 놓였을 때 전달자가 느리거나 비활성화 상태이면, 메시지는 QM1에서 영속할 수 있다. 결국 전달자가 그 메시지를 이동시킬 때, 사용자 애플리케이션이 활성화된 경우, 그 메시지는 QM2에서 영속될 필요가 없을 수도 있다. 이는 메시지를 영속적으로 저장하거나 메시지에 수행되는 동작을 영속적으로 로그하는 것이 바람직한 지와 그 시기를 융통성 있게 동적으로 판정할 수 있다는 효과의 일 예에 지나지 않는다. 다른 예들은 이하 '실시예'에서 설명한다.

본 발명의 일 실시예는 메시징 시스템을 통한 메시지 처리 도중에 메시지의 영속성을 관리하기 위한 방법을 제공하며, 이 방법은 메시지 관련 데이터가 영구 저장소로의 저장을 필요로하는 지를 판정하기 위해 그 데이터를 영구 저장소에 저장하는 비용, 및 그 데이터를 영구 저장소에 저장하지 않는 경우 이와 관련된 리스크를 나타내는 기준 세트 중 적어도 하나의 기준을 평가하는 단계; 및 영구 저장소로의 저장이 필요한 지를 판정하는 평가 단계에 따라 그 메시지 관련 데이터를 영구 저장소에 저장하는 단계를 포함한다.

제2 실시예는 데이터베이스내에서 데이터의 영속성을 관리하기 위한 방법을 제공하며, 이 방법은 데이터가 영구 저장소로의 저장을 필요로 하는 지를 판정하기 위해 그 데이터를 영구 저장소로 저장하는 비용 또는 이익을 나타내는 적어도 하나의 기준을 평가하는 단계; 및 영구 저장소로의 저장이 필요한 지를 판정하는 평가 단계에 따라 그 데이터를 영구 저장소에 저장하는 단계를 포함한다. 평가는 데이터베이스에 영향을 미치는 동작 세트에 대해 또는 특정한 데이터의 삽입, 삭제 또는 업데이트에 대해 수행될 수 있다.

본 발명의 또 다른 측면은 위에서 기술한 방법을 구현하기 위한 영속성 관리자, 예를 들어, 데이터베이스 또는 메시징 시스템을 포함하는 데이터 처리 시스템을 제공한다. 본 발명의 일 실시예에 따른 데이터 처리 시스템은 휘발성 데이터 저장소; 비휘발성 데이터 저장소; 비휘발성 데이터 저장소에 유지되는 데이터 테이블에 데이트 업데이트를 하기 위한 데이터베이스 관리자; 및 데이터 업데이트가 비휘발성 데이터 저장소로의 저장을 필요로 하는 지를 판정하는 영속성 관리자를 포함한다. 영속성 관리자는 데이터 업데이트가 비휘발성 데이터 저장소로의 저장을 필요로 하는 지를 판정하기 위해 비휘발성 데이터 저장소로의 저장하는 비용 또는 이익을 나타내는 적어도 하나의 기준을 평가하고, 그 후 판정 결과가 긍정이면, 비휘발성 데이터 저장소에 데이터 업데이트의 저장을 개시한다.

일 실시예에 따른 메시징 시스템은 RAM과 같은 휘발성 데이터 저장소; 디스크 저장소와 같은 비휘발성 데이터 저장소; 메시지 전달을 처리하기 위한 메시징 관리자; 및 메시지 관련 데이터가 비휘발성 데이터 저장소로의 저장을 필요로 하는 지를 판정하기 위한 영속성 관리자를 포함한다. 영속성 관리자는 메시지 관련 데이터가 비휘발성 데이터 저장소로의 저장을 필요로하는 지를 판정하기 위하여, 비휘발성 데이터 저장소로의 저장 비용 또는 이익을 나타내는 적어도 하나의 기준을 평가한다. 영속성 관리자는 메시지에 관해서 동작이 수행될 때 또는 그 후 현재의 자원 비용 및/또는 저장소로의 저장 이익을 참조하여 이러한 판정을 동적으로 수행할 수 있다. 영속성 관리자는 영구 저장소로의 저장이 필요한 지를 판정하는 평가 단계에 따라, 메시지 관련 데이터를 비휘발성 데이터 저장소에 저장하는 것을 개시한다.

본 발명의 일 실시예에서는, 로그 기록이 임박할 때 영구 저장소로 저장할 지에 대한 판정이 이루어져, 로그 기록에 어느 동작이 포함되어야 하는 지를 검사한다. 또 다른 실시예에서는, 비동기적 경고 에 의해서 ― 예를 들어,이러한 큐를 처리 중인 애플리케이션 프로그램 또는 메시지 채널 에이전트가 셧다운되거나, 또는 큐의 깊이가 메시지의 임계 개수를 초과하거나, 또는 메시지가 밀리초의 임계 시간보다도 오래 큐잉되었던 경우에 따라 ― 판정이 트리거된다.

본 발명의 제3 측면은 위에서 설명한 방법을 구현하도록 데이터 처리 시스템내에서의 동작 수행을 제어하기 위한 명령어 세트를 포함하는 컴퓨터 판독 가능 매체를 제공한다. 컴퓨터 판독 가능 매체는 바람직하게는 컴퓨터 프로그램 제품으로서 제공되며, 여기서 명령어 세트는 기록 매체 또는 데이터 전달 매체상에 기록되는 컴퓨터 프로그램으로 구현된다. 이러한 컴퓨터 프로그램 코드는 데이터 통신 매체를 통해서 전달되는 데에 이용될 수도 있다.

본 발명의 실시예는 예로서 첨부 도면을 참조하여 보다 상세히 설명한다.

도 1은 기술 분야에 공지된 바와 같이 간단한 분산형 메시징 시스템의 개략도이다.

도 2는 본 발명이 구현될 수 있는 메시징 시스템의 개략도로서, 본 발명의 일 실시예에 따라 영속성 관리를 행하는 데 조업할 수 있는 시스템 구성요소들을 도시한다.

도 3은 도 2의 실시예에 따른 메시징 시스템의 구성요소들 중 일부 구성요소 들의 보다 상세한 도면을 도시한다.

도 4A 및 4B는 본 발명의 일 실시예에 따른 영속성 관리 방법의 단계를 나타내는 간략화된 순서도이다.

도 5는 본 발명의 또 다른 실시예에 따른 방법의 단계들을 도시하는 간략화된 순서도이다.

도 6은 본 발명의 또 다른 실시예에 따른 데이터베이스 관리 시스템의 개략도이다.

본 발명은 단일 데이터 처리 시스템(single data processing system)이나 분산형 데이터 처리망내에서 실행될 수 있는 것으로, 영속성(persistence)을 유지하기 위해 새로운 접근방법을 이용해서 기존의 데이터 처리 시스템에 비해 높은 융통성(flexibility)을 제공한다. 아래는 발명의 제1 실시예로서 메시징 네트워크에 사용된다.

기존의 분산 메시징 네트워크는 통신 링크(20)에 연결된 복수의 자료처리시스템(10, 15)을 포함한다. 간단한 네트워크의 예로 두 개의 데이터 처리 시스템만이 연결된 것이 도 1에 나타나 있지만, 메시징 네트워크는 수 백개의 분리된 데이터 처리 시스템으로 구성될 수도 있다. 메시징 네트워크에 속한 각각의 데이터 처리 시스템(10, 15)은 컴퓨터 프로그램 코드나 전자 회로안에서 사용되는 하드웨어에서 실행되는 메시징 관리자(30, 35)를 포함한다. 특정 데이터 처리 시스템(10) 의 메시징 기능(messaging functions)들은 비즈니스 프로세싱을 수행하는 애플리케이션 프로그램(40, 41)을 구성으로 가지지만, 본 실시예는 컴퓨터 프로그램안에서 실행되는 애플리케이션 프로그램(40, 41, 45)과 메시징 관리자(30, 35)들은 분리되어 있다. 애플리케이션 프로그램(40, 41, 45)들은 메시징 네트워크를 통해서 상호간에 통신할 수 있고, 각각은 메시지 인터페이스(API)(50, 55)를 통해서 로컬 메시징 관리자 프로그램(30, 35)과도 통신할 수 있다. 각각의 메시징 관리자(30, 35)는 하드웨어 프로세서의 처리기능과 데이터 처리 시스템을 작동시키는 운영체제(Operating system)에 의해 제공되는 서비스에 의존하며, 메시징 관리자들은 시스템과 네트워크 간의 OS차 문제를 해결하는 데 필요한 모든 데이터 변형들을 다룬다. 상기 구성들[데이터 처리 시스템, RAM(random access memory)(70, 75), 비휘발성 디스크 저장소(non-voltile disk storage)는 통신 버스(communications bus)를 통해 연결된다.

본 발명은 기존의 데이터 처리 시스템 하드웨어와 OS구조에도 적용될 수 있으므로, 알려진 데이터 처리 시스템의 기본 형태들은 여기에서 더 이상 서술하지 않겠다.

도 1의 메시지 시스템의 구조는 상대적으로 간단한 애플리케이션 프로그램의 개발을 용이하게 하며, 전형적인 이종 분산형 데이터 처리 환경내의 다양한 구성요소들 세트간에 집적 및 상호작용과 관련된 많은 문제들을 해결한다. 공통적인 메시징 기능들은 메시징 관리자(30, 35)안에서 실행될 수 있고, 애플리케이션 프로그램(40, 41, 45)은 각각의 로컬 메시징 관리자 기능을 메시지 API(50, 55)을 통해 호출하기 위해서 작성될 수 있다. IBM Corporation의 WebSphere MQ 메시징 관리자 프로그램과 같은 메시징 관리자(30, 35)는 메시징 관리자에 의해 관리되는 메시지 큐(message queues)를 통해 비동기 메시지 통신을 제공한다.

예를 들어, 첫째 데이터 처리 시스템(10)에서 작동하는 애플리케이션 프로그램(40)은 메시지를 로컬 메시징 관리자(30)에 의해 관리되는 전송 큐(transmission queue)에 위치시킴으로써 원격 애플리케이션 프로그램(45)과 통신한다. 메시지 큐는 메시지들을 한 프로그램에서 다른 프로그램으로 보낼 때 그 경로를 유지시키기 위한 것으로, 상응하는 메시징 관리자에 의해서 확보된 단순한 기억장치의 영역이다. 비록 메시징 관리자의 구성를 도 1에서 도식적으로 나타내었지만, 메시지 큐(100, 105, 110)들은 휘발성 랜덤 액세스 메모리(volatile random access memory)(70, 75)에 의해 고정되고, 밑에 묘사된 것과 같은 영속성 관리자(persistence manager)(80, 85)의 통제안에서 디스크 기억장치(90, 95)에 의해 강화된다.

통신 채널(25)은 통신 링크(20)를 통해서 한 쌍의 메시지 채널 중 개체(60, 65)(혹은 운반자(전달자))사이에 즉, 첫째 시스템(10)과 원격 시스템(15)간을 연결한다. 로컬 메시징 관리자는 어느 메시지가 라우팅(routing)되야 하는지 망내에서 다음 메시징 관리자를 결정하기 위해 전송 큐(100)에 자리잡은 메시지의 헤더를 검사한다. 그 후 운반자(60, 65)들은 전송 큐(100)에서 제2 메시징 관리자(35)에 의해 관리되는 큐로 적절한 메시지를 전달하는 것을 책임진다. 만약 제2 메시징 관리자가 목적 메시징 관리자로 가기 위한 길의 중간 지점일 뿐이라면, 새로운 큐는 다시 메시지가 다음 네트워크 지점까지 전진할 수 때까지 메시지의 임시 저장소 역할을 하는 전송 큐(105)이 된다. 그러나 만약 제2 메시징 관리자(35)가 목적지인 애플리케이션 프로그램(45)을 위한 로컬 메시징 관리자라면, 메시지는 애플리케이션이 메시지를 처리하기 위한 준비가 되었을 때 애플리케이션 프로그램(45)에 의해 제공된 애플리케이션 입력 큐(110)에 자리잡을 것이다.

메시지를 첫째 전송 큐(100)에 위치시키거나, 메시지를 애플리케이션 입력 큐(110)로 이동시키거나, 애플리케이션 프로그램(45)이 메시지를 입력 큐(110)에서 검색하는 단계들은 지속적일 필요없이 비동기적으로 수행되며, 애플리케이션 프로그램(40, 45) 사이에서 떨어져 있다. 비록 도 1에 나타나 있지는 않지만, 네트워크를 통해서 첫째 송신 시스템(10)과 원격 목적 시스템(15) 사이에 복합적이고 비동기적인 활동이 있다.

기존의 메시지 시스템 안에서는, 메시지들은 시스템 관리자나 송신 애플리케이션에 의해 분류된 것에 따라 지속적이거나 일시적으로 전송된다. 영속성 관리자(persistence manager)(80, 85)는 통신 애플리케이션 프로그램이나 메시징 관리자의 요구에 의해 명기된 영속성에 따라서(혹은 이러한 애플리케이션이나 메시징 관리자 상호 간에 보내진 모든 메시지들의 요구에 따르거나 특정 메시지만의 요구에 따라서) 영구 저장소(90, 95)로 (예를 들면 비휘발성 디스크 기억장치기억장치를 작성한다. 영속성 메시지는 메시지가 첫째 전송 큐(100)에 위치할 때 전송자 애플리케이션의 로컬 메시징 관리자(30)에 의해 로컬 영구 저장소(90)에 저장된다. 그리고 로컬 로그 레코드(local log record)는 메시지가 전송 큐(100)에 놓여질 때 와 메시지가 전송 큐(100)에서 애플리케이션 입력 큐(110)로 성공적으로 이동할 때 모두 로컬 영구 저장소(90)에 작성된다. 메시지와 이와 연관된 로그 레코드들은 둘째 시스템(15)에서 메시지가 애플리케이션 입력 큐(110)에 놓여질 때 둘째 영구 저장소(95)에 작성되며, 로그 레코드는 메시지가 큐(110)에서 목적 애플리케이션 프로그램(45)에 의해 검색되었을 때 역시 작성된다.

메시지 시스템 안에서, 로그 레코드가 뒤따르는 시스템의 고장을 복구할 수 있어야 하므로, 로그 레코드는 메시지를 큐 위에 놓거나, 흔히 완료(complete)라고 정의되는, 큐로부터 메시지가 검색되는 작업 전에 작성돼야만 한다. 다만, 큐의 영속성 카피(persistence copy)에 대한 업데이트는 '느리게(lazily)' 기록될 수도 있다(백그라운드 작업처럼, 보통의 시스템 고장시에는 느린 기록을 강제하는 것을 예외로 함).

재생성(recoverability)과 로그 레코드를 영구적으로 기록시 달성할 수 있는 메시지 전달의 확실성이라는 장점에도 불구하고, 이러한 디스크 쓰기는 주목할만한 병목현상(bottleneck)이 있다. 기존의 시스템들은 로그 레코드들이 디스크에 강화되는 횟수를 줄여줄 수 있는(즉, 영구 저장소에 매번 올리고, 받고, 다른 업데이트 작업을 하는 대신에 행해진 일의 단위마다 작성하는 것) 분산된 처리를 지원한다. 많은 동작들이 평행하게 작동되는 몇몇의 시스템들은 수개의 작업을 하나의 버퍼에 그리고 그것들을 동시에 하나의 디스크에 놓는 식으로 로그 레코드들을 결합시킨다. 이러한 특징들이 작업능률을 향상시키지만, 영속성(persistence)과 로그(log)를 다루는 것이 작업의 병목현상을 가져온다.

하나의 작성된 시스템에서, 사용자들은 상이한 시스템 상태를 만들기 위해 상이한 영속성 작동이 가능하도록 의도한 영속성의 정도를 설정할 수 있다. 하지만, 그 작용은 영속성의 요구치가 설정되었을 때 미리 정해지므로, 실제 융통성(flexibility)은 현재 주위상황의 역동적인 반응, 비용, 영구 저장소에 저장되는 이익과 비용의 측면에서 볼 때 달성되지 않는다.

본 발명은 미리 정해진 한계와 정해진 영속성의 불가변한 수치를 제거하여 뛰어난 융통성(flexibility)을 제공한다. 몇몇의 영구저장작업들은 (persistent save operations) 메시지 값을 과 영구 저장소에 저장하는 이익과 비용에 기초하여 영구 저장소에 저장할 지에 대한 결정을 내림으로써 완전히 피할 수 있다. 비용과 이득의 기준은 메시지 송신부에서부터 메시지 목적지에 이르는 메시지 과정을 통해 메시징 네트워크 안에서 다양한 관점에 따라 평가될 것이다.

제1 실시예에 따르면 메시지 시스템(10)은 밑에서 도 2를 참조하여 표시되어 있다. 애플리케이션 프로그램(40, 41)들은 메시징 관리자(30)를 통해 상호간에 영향을 끼칠 수 있고 다른 애플리케이션(네트워크 다른 어딘가에 위치하고 있을)과도 영향을 주고 받을 수 있다. 메시징 관리자(30)는 애플리케이션 프로그램에 의해 만들어진 API 응답에 따라 네트워크 안에서의 메시지의 전송을 다루며, 로컬 데이터 처리 시스템(10)에서 이용가능한 네트워크 통신특성과 OS 특성을 이용한다. 메시지 로컬 애플리케이션 프로그램, API(50)와 메시징 관리자(30)들은 도 2에 도식적으로 나타나있다. 휘발성 랜덤 액세스 메모리(70)과 비휘발성 디스크 기억장치(90)들 역시 도 2에 도식적으로 표현하였다.

애플리케이션이 메시지를 생성할 때, 영속성 속성은 메시지와 연관되어 있다. 이미 공지된 것처럼, 영속성 속성은 '영구적' '일시적' '메시지가 위치한 큐에서 근거한 영속성인 제3 의 상태'로 분류될 수 있다. 영속성 속성은 매 메시지(애플리케이션이나 메시지가 위치한 큐에서 디폴트 메시지 디스크립터 조건(default message descriptor setting)을 사용하는)마다 자동적이며 고정적으로 설정될 것이며, 애플리케이션 프로그램은 개개의 메시지가 영구적인지 일시적인지 구분하기 위해 메시지 디스크립터안에서 영속성 영역을 선택적으로 사용할 것이다. 전형적인 메시지 시스템에서, '영속적' 메시지는 영구 저장소(persistent storage)에 저장될 것을 요구하는 반면에 '일시적' 메시지는 그것의 손실(즉, 우발적인 메시지 손실)이 애플리케이션에 의해 통제되기 때문에 영구 저장소(persistent storage)에 저장될 필요가 없다. 그러므로, 애플리케이션에서 분류된 영속성 속성은 기존 메시지 시스템의 다음 동작을 특징짓는다. 메시지를 읽고 검색하는 프로그램은 영속성 속성에 액세스할 수 있고, 어떠한 메시지가 동일한 영속성으로 보내지더라도 메시지에 응답하는 것을 안전하게 할 것이다.

기존의 메시지 시스템에서, 메시지는 구체적인 데이터(종종 메시지 내용이나 메시지 페이로드(message 페이로드(payload))라고 불리는)와 메시지 헤더(메시지 디스크립터(MQMD)와 다른 구조영역을 포함하는)라는 서로 다른 2개의 애플리케이션 파트로 이루어져 있다. 애플리케이션 데이터는 어느 특정한 데이터 타입으로 제한되어 있지 않고 캐릭터 스트링(character strings), 바이트 스트링(byte strings), 바이너리 정수(binary integers), 소숫점 수(floating point numbers)등 과 같은 것들을 모두 포함한다. 조직된 영역(structured fields)들은 메시지를 생성하는 메시징 관리자(30)를 위한 버젼 번호(version number), 시간 연속 순서에 따른 메시지를 다루는 클럭 값(clock value), 데이터 길이, 가능한 종료 간격등과 같은 정보들을 포함한 메시지의 디스크립션을 수용하고 있다. 메시지 디스크립터는 전송자 애플리케이션 프로그램(40)에서 메시징 관리자(30)로 보내어지며, 메시징 관리자(30)에 의해 수신측 애플리케이션 프로그램(45)로 다시 보내진다. 메시지 디스크립터(message disk discriptor)는 만약 전송자 애플리케이션 프로그램에서 요구한다면 영속성 속성(MQMD.persistence)와 우선권 속성(MQMD.priority)를 포함한다. 우선권 속성은 전송자 애플리케이션들이 메시지의 긴급성을 표시하기 위해 제공되며, 메시지 큐에서 메시지의 순서를 정할 때 메시징 관리자가 우선권을 참작할 것이다. 그러나, 목적 큐은 우선권 속성이 무시되는 선착순 큐(FIFO queue)의 특성을 가질 것이다.

상기 서술한 대로, 본 발명은 영속성 관리에 대한 융통성 있는 접근이지만, 몇 개의 실시예들은 위에서 서술한 영속성 속성을 이용하고 있다. 첫째 실시예에서, 영속성 속성은 영구 저장장치에 저장하는 이득이 비용을 정당화시키는지 판단할 때, 메시지가 항상 일시적인 특성(상기 언급했듯이 일시적인 메시지의 기존의 조작)으로 조절돼야 하는지 혹은 영구적인 특성으로 조절돼야 하는지를 지시해준다. 전송자 애플리케이션에 의해 영구적이라고 분류된 메시지들은 메시지 작성자가 메시지를 보낸 후 영속성의 속성을 결정한다. 이렇게 '표면적으로 영구적인' 메시지를 위해 결정된 비용/이득구분은 영속성을 메시지가 보내진 후에 메시지 시 스템안에서 동적인 기준에 따라 결정하지 않는다는 점에서 기존의 방법들과 다르다. 이 실시예에서, '표면적으로 영구적인' 메시지는 항상 영구적으로 메시지들을 저장하는 대신에 메시지 시스템에 의해 메시지가 조정될 때 평가된 기준의 묶음(즉, 하나 이상의 기준)에 의해 설정된 영구 저장소에 저장할 뿐이다.

전송자 애플리케이션 프로그램(40)은 특정 애플리케이션 메시지 데이터와 메시지 디스크립터를 통해 분류함으로써 새로운 메시지를 큐에 놓는다. 메시지 디스크립터는 목적 메시지 큐와 목적 메시징 관리자(35) 식별하며, 이는 메시지가 추가될 첫째 메시지 큐를 식별하는데 사용된다. 메시징 관리자의 네트워크는 첫째 메시지 큐에서부터 목표 애플리케이션 프로그램의 입력 큐까지의 메시지의 전송을 제어한다.(어떤 경우에는 메시징 관리자는 동일한 데이터 처리 장치에 의해 작동되는 두개의 애플리케이션간의 통신을 지원할 수 있지만, 대부분의 경우 메시징 관리자의 분산된 네트워크는 물리적으로 떨어진 네트워크에서의 비동기식 메시지 전송을 지원한다.)

메시징 관리자나 수신측 애플리케이션이 메시지를 각각의 전송 큐이나 입력 애플리케이션 큐에서 검색할 때, 메시징 관리자나 수신측 애플리케이션 프로그램은 정보들을 검색되어질 메시지로 분류하고, 메시지가 삽입될 버퍼 기억장치의 빈 영역으로 분류한다(그리고 버퍼 기억장치의 빈 영역의 길이로 분류한다). 검색한 메시징 관리자는 구분된 영속성 속성에 따라서 메시지를 프로세스한다.

제1 실시예에서, 일시적이고 '표면적으로 영구적인' 메시지들은 메시지 순서를 간단하게 하고 오류에서 효율적으로 회복시키기 위해 하나의 메시지 큐안에서 분리된 장소(120, 130)에 놓여진다. 이러한 방법은 미국 특허 제 5,452,430호에 서술되어 있다 - 다만 여기에서는 영속성 속성이 영구 저장소에 저장되는 이득과 비용에 대한 고려없이 일정한 영속성값을 지닌다. 본 실시예에서, 한면에 있는 메시지가 영구적으로 저장될 필요가 없는 일시적인 메시지를 할당하지만, 다른면에 있는 메시지는 비휘발성 디스크 기억장치에 작성하기로 된 표면적으로 영구적인 메시지들을 할당한다. 실제로 데이터를 디스크 기억장치에 작성하기 전에, 영속성의 이득과 비용요인에 대한 평가가 행해진다.

영속성의 이득과 비용에 대한 평가(evaluation)는 다양한 시간에 행해지고 다수의 요인들이 고려될 것이다. 우선, 메시지가 메시징 네트워크를 통과하는 경우, 평가 메시지가 최초로 메시징 관리자에 의해서 큐에 기록될 때 메시징 관리자를 통해서 이루어진다. 이것이 유용한 메시지들을 영구 저장소에 즉시 저장되는 것을 가능하게 한다. 또 다른 신속한 평가(evaluation)의 동작인 '트리거 이벤트'는 메시지 시스템 -주어진 큐가 경계 크기에 이르렀을 때, 혹은 개개의 메시지가 경계시간 동안 배열되었을 때의 시스템- 안의 동작에서 비롯될 수 있다. 평가(evaluate)는 또한 로그(log)의 작동에 의해서 유발될 것이며(예로써 로그 버퍼(log buffer)를 1밀리세컨으로 만드는 시스템의 자각에 쓰일 수 있다), 이러기 위해서 추가적인 동작이 매우 낮은 오버헤드(overhead)와 동시에 기록될 수 있다. 이 경우에, 남아있는 특정 로그 레코드와 연관된 낮은 리소스 이득은 로그 레코드가 디스크에 다른 경우보다 빠르게 작성됨을 의미한다. 다른 '트리거 이벤트(trigger event)'는 시스템 이벤트(events)를 포함한다; 예로써 메시징 관리자가 임박한 시스템 정지나, 잠재적인 시스템 오류를 경고하였을 때를 들 수 있다. 후자는 디스크 기억장치 보조시스템이 불량 섹터의 모습을 찾아냈을 때 감지된다.

이러한 '트리거 이벤트'와 영구 저장소에 저장하는 이득과 비용의 평가를 위한 경계는 각각의 메시지에 맞게 유동적일 것이다. 예를 들면,메시지가 처음으로 큐에 놓여질 때 메시징 관리자에 의해서 행해지는 평가는 메시지가 상당한 가치를 가졌는지, 즉시 작성할 만큼의 가치는 없는지를 결정할 것이다. 이러한 최초의 평가는 '트리거 이벤트'가 특정 메시지에서 행해진 후에 짧은 시간에 걸쳐 이루어진다. 주기가 끝날 무렵에(즉, '트리거 이벤트(trigger event)'가 일어났을 때), 메시지는 더 이상의 평가 없이 디스크로 보내질 수 있고, 두번째 평가가 행해질 수도 있다.

최초의 평가가 중요한 과정('메시지 값'(이하 서술된다)이나 다른 데이터를 결정하는 것과 같은)을 수반하기 때문에, 제1 실시예에서 첫 평가를 위해 수집된 데이터는 네트워크와 수집된 데이터가 재활용되는 동일한 메시지에 의해 행해지는 뒤의 평가로 들어간다. 한 실시예에서는, 계산된 메시지 값이 메시지와 함께 통과되거나, 연결된 메시징 관리자 안에서 영속성의 평가가 효율화되기 위해 통신 프로토콜이 확장된다. 다른 실시예에서는, 메시지 값이 조건으로 지정되기 위해 -예를 들면 메시지 헤더의 추가적인 영역 안에서(더 자세한 것은 밑에 주어져 있다) 가능하도록- 메시지 API가 확장된다.

각각의 메시징 관리자(30)에서, 데이터 수집 구성(140)은 로컬 시스템에 있는 메시지의 이득과 비용에 대한 평가에 사용하기 위해 구체적인 메시지 데이터(메 시지 값과 조금더 일반적인 메시지 프로세싱 통계를 포함한)의 수집을 유지한다. 규칙의 세트는 규칙의 기억장치(150)에 있고 영속성 관리자(80)의 평가 구성(160)에 의해 수집된 데이터를 적용시키게 된다. 수집기 구성(140)는 다량의 정보를 프로세싱 동작의 분석과 메시징 관리자(30)안의 데이터 구조에서 추출하며, 이러한 정보를 이용하여 데이터베이스 세트를 업데이트한다.

메시지 값은 메시지관리자에 의해 여러가지 방법 중 한가지로 결정된다. 예를들어, 메시지 값은 메시지 타입이나 메시지가 놓여진 큐과 연관된 룰(rule)들에 기초하여 계산된다. 다른방법으로, 메시지 값은 메시지 내용의 분석(예를들면, 메시지 내용 안의 어디에서 통신 애플리케이션 프로그램들이 값과 전송들을 조절하고 어디에서 분류되는지)에 따라 수신측 메시징 관리자에 의해 결정되거나, 메시지 헤더안의 메시지 값 영역을 참조하여 결정된다. 후자의 예는 메시지 값이 메시지 API를 지나 전송자 애플리케이션에 의해 분류되는 경우(밑을 참조하여라), 혹은 메시지 값이 전송자 애플리케이션의 로컬 메시징 관리자에 의해 한번만 산출되었을 때 적용될 수 있다.

Service Oriented Architectures(SOA)와 같은 고난도의 구조에서는, 시스템의 구조가 큐, 큐에 있는 메시지를 위한 메시지 타입, 이런 메시지 타입의 포맷(format), 메시지와 프로세싱과 관련된 다른 시맨틱 정보(semantic information)사이에서 조합된 것이 보편적이다. 본 발명의 SOA구조에서, 시맨틱 정보(semantic information)들은 메시지 값(혹은 SOA 구조안에서 이러한 값을 계산하기 위한 구성들)을 포함한다. 이 정보들은 메시지 API의 프로그래밍 없이 고도의 시맨틱 성분 들에 의해 메시징 관리자로 전송된다. 메시징 관리자는 이러한 메시지 값이 메시지 API를 따라 직접적으로 제공되었는지 혹은 고도의 SOA 시스템을 거쳐서 결정되었는지 인식할 필요가 없다.

보다 근본적인 시스템에서는, 메시지의 시맨틱(semantic)을 이해시키고 메시지 값을 추출하거나 얻어낼 수 있는 API crossing exits를 사용함으로써 비슷한 효과가 나타난다. 즉, 메시지 값은 애플리케이션 프로그래머에 의해 작성되는 것이 필요한 API 코드 없이 메시지 시스템으로 전송된다. 다시 말하면, 메시지 시스템은 메시지 값 정보의 근원을 인식할 필요가 없다.

큐의 깊이 또한 표시되고(기존의 메시지 시스템처럼) 이 데이터는 데이터 수집기 구성(140)에 제공된다. 게다가, 메시지가 큐에 남아있는 시간도 큐에 있는 데이터 항목의 총 데이터 크기와 함께 표시된다(그리고 이러한 표시는 기존의 메시지 시스템에서 명확히 표시되지는 않았지만, 이미 이용가능했으므로 오버헤드(overhead)를 거의 포함하지 않는다). 게다가, 큐로부터 읽는 메시지 비율과 메시지가 큐에 남아있는 시간도 -큐의 헤드(head)로 도달하는데 걸리는 예상시간과 같이 더 발전된 통계적 수치들과 함께- 표시된다. 기존의 시스템에서 종종 표시되던 CPU 오버헤드는 시스템의 또 다른 특성으로써, 매우 큰 CPU 부하가 종종 시스템 오류와 관련있기 때문에 영속성 평가에 중요할 것이다. 게다가, 영구적인 저장동작이 이루어지는지 아닌지에 따라 기존의 몇몇 프로그램들은 다른 프로그램에 역효과를 가졌다.

제1 실시예에서, 메시징 관리자(30)은 내부 메시지 프로세스 효율을 표시하 고, 수집기 구성(140)에 초당 큐로부터 읽어온 메시지 수의 값을 제공한다. 수집기 구성은 기하급수적인 스무딩 알고리즘(exponentialy smoothing algorithm)을 데이터베이스에 저장된 값을 발생시키려 불러온 메시지비율(messageProcessingRate)에 적용한다. 또한 수집기 구성(140)은 각각의 메시지 큐에 있는 개별 메시지의 위치(positionInQueue)를 표시한다. 이러한 positionInQueue 값은 메시지가 큐에 첨가될 때 정해지며, 순차적으로 업데이트될 수 있다.

또한 메시징 관리자의 수집기 구성(140)은 오류(메시징 관리자, OS 혹은 데이터 프로세스 시스템 하드웨어에서 발생하는 모든 오류를 포함함) 시간의 통계적인 평균값(meanTimeToFailure)을 생성한다. 그 밖의 통계자료(이미 표시된 디스크 쓰기 에러와 같이 존재하던 시스템 관리 자료)와 뇌우, 전기공급의 신뢰성, 지진의 위험과 같이 시스템 오류와 관계있는 외부 요인들도 똑같이 사용된다.

수집기 구성(140)은 메시지 시스템의 현재 부하를 나타내는 값(load), 메시지 시스템의 평균적인 부하를 나타내는 통계적인 값(avgLoad)과 영구 메시지에서 초당 쓰여지는 평균 디스크의 수(persistPerSec)를 -메시징 관리자(30)나 OS로 부터- 얻는다.

timeInProcess의 하나 혹은 그 이상의 값들은 메시지가 큐의 헤드에서 검색된 후 메시지를 프로세싱하는데 걸린 시간을 나타내기 위해 보존된다. 예를 들어, 현재 메시징 관리자(30)가 목표 애플리케이션 프로그램의 입력 큐을 관리하는 목표 메시징 관리자인 경우에, timeInProcess는 'get_message' call을 부르는 로컬 애플리케이션에 의한 메시지의 검색과 메시지 검색 동작의 완료사이의 시간이다. 메시 징 관리자가 전송자 애플리케이션의 메시징 관리자와 목적 애플리케이션의 메시징 관리자 사이의 중간 프로세스 노드인 경우에는, timeInProcess는 로컬 전송 큐의 헤드에서부터 검색된 메시지와 다른 노드로 메시지를 전송하기 위해 메시지 전송동작이 완료되는 사이의 시간을 의미한다.

상기의 데이터를 가지고 데이터베이스를 업데이트 시킬때, 데이터는 규칙 저장소(150)에 있는 규칙 세트를 적용시키기 위한 영속성 관리자(80)의 평가 구성(160)에 의해 프로세스된다. 평가 구성는 메시지가 메시지 큐의 헤드에 도달하는 대략적인 시간(timeToHeadOfQueue)을 평가하기 위해 positionInQueue와 messageProcessingRate 값을 프로세스한다.

timeToHeadOfQueue = positionInQueue / messageProcessingRate

평가 구성는 또한 메시지가 메시징 관리자에 의해 남겨질 대략적인 시간(timeHeld)을 계산한다.

timeHeld = timeToHeadOfQueue + timeInProcess

특정한 메시지가 손실될 위험량은 메시지가 남겨질 시간과 오류사이의 평균시간을 고려하여 계산된다.

riskOfLoss = min(1, timeHeld / meanTimeToFailure)

이렇게 메시지가 손실될 위험량의 평가는 영구 저장소에 저장할지 아닌지를 결정한다. 영속성 관리자(80)의 평가 구성(160)에 의한 이러한 예비적인 평가 과정은 메시지의 값을 생각하지 않고 특정 메시지의 손실 위험만을 고려한다. 비록 몇 개의 실시예가 메시지 손실의 위험을 평가하고 메시지 값에 대한 고려없이 필요 한 영속성을 결정하지만, 개개의 메시지 값에 기초한 메시지 손실의 대가를 고려하는 것이 권장된다(혹은 메시지 수행 통계치와의 조합이나 리소스 비용을 고려해보라). 이러한 방법으로, 메시지 손실에 대한 대가를 나타내는 값은 메시지 손실에 대한 위험을 표시하는 값과 시스템 리소스의 요구치와 관계있는 추가적인 기준과 함께 결합 될 수 있다. 예를 들어:

riskCost = messageValue * riskOfLoss

persistenceCost 값은 load와 avgLoad값 persistPerSec 값을 참고로 하여 평가될 것이며, 만약 riskCost가 persistenceCost를 초과할 때는 데이터를 영구 저장소에 저장하기 위해 만드는 것을 고려하여 평가될 것이다(여기서 persistenceCost는 영구 저장소에 저장하기위해 필요한 리소스에 기초할 것이다). 또한 시스템 작동에서 지속된 효과치는 영속성을 결정하는데 평가되고 사용될 것이다.

if(riskCost > persistenceCost) then persistence=true

if(riskCost ≤ persisstenceCost) then persistence=false

영속성의 결정은 메시지 시스템이 동작 또는 일단 확실해진 메시지 전달의 우선 순위를 결정하는지 아닌지에 근거할 것이다(이는 특정한 소비자의 메시지 애플리케이션을 위한 약관 품질의 요구에 따른다.).

상기와 같은 간단한 룰(rule)조차도 메시지 프로세스 시스템의 대가의 효율성을 증가시기는 방향으로 실행될 수 있다. 비록 상기 룰(rule)이 작동 가능성을 증명하고 어떻게 발명의 동적 원리들이 구체화되는지를 나타내지만, 다수의 다른 룰(규칙)들은 영속성을 결정하는데 사용된다. 이러한 룰들(rules)은 위의 예보다 훨씬 복잡하며, 영속성 관리자에 사용할 수 있는 정보들에 의존한다.

도 3은 수집기(140)와 영속성 관리자(80)의 평가 구성(160)를 발명의 한 실시예에 맞추어 더 자세하게 나타낸 것이다. 구성(141)는 메시징 관리자 자체에 의해 제공된 정보(큐의 깊이, 큐에서 각각의 메시지의 위치, 개별 메시징 관리자의 내부 메시지 프로세스 비율을 포함한다)의 수집기이다. 수집기(140)은 또한 시스템 부하와 관련된 데이터(예를 들면, 오류의 평균시간, 디스크 쓰기 오류를 감지하는 것과 관련된 정보)를 제공하는 분리된 외부 수집기 구성(142)를 포함한다. 구성 141과 142는 모두 그들의 데이터를 수집 데이터베이스(143)-평가자의 평가 프로세스 구성(162)에 의해 사용되는 표시된 데이터 소스-에 제공한다. 평가자(160)은 또한 내부 외부 수집기 구성 141과 142에 의해 발생된 동작, 영구적인 쓰기와 연관된 종료의 한주기 시간에 반응하는 트리거 구성(161)을 포함한다. 규칙 저장소(150)는 하나 혹은 그 이상의 (ⅰ) 메시징 관리자의 동작을 구체화 시키는 조건과 관련된 규칙 (ⅱ) 데이터 프로세스 시스템안의 조건과는 관련있지만 메시징 관리자의 내부작동과는 관련없는 규칙(rule)을 포함할 것이다. 비록 도 2와 도 3에서 메시징 관리자(30)의 내부 구성를 나타내었지만, 영속성 관리자(80)의 전체 혹은 몇몇의 구성들은 서로 분리되어 있지만 매시지 관리자(30)와 협력하는 데이터 프로세스 시스템(10)의 하나 혹은 그 이상의 구성들에 의해 채워진다.

통화 기록에 따라 전화비용을 계산하는 애플리케이션을 고려해보자. 몇몇 기록들이 상당량(50 센트 혹은 1 달러)이고 통화기록의 적은 비율이 수 달러인 반면에, 다수의 기록들은 약간의 센트(cents)일 뿐이고 몇몇은 실제 값이 없다. 요 금 애플리케이션은 통화기록의 높은 값을 잃어서는 안되지만(따라서 이는 항상 영구적으로 다루어져야한다), 경계보다 적은 기록들은 영구적인 조절의 비용을 자리맞춤시키는 충분한 값을 가질 필요가 없다. 신뢰할만한 데이터 프로세스 시스템과 함께, 에러와 오류는 상대적으로 드물어지며 약간 있는 작은 값의 통화 기록들은 프로세스 동작의 향상을 위해 묵인될 수 있다. 중간 값의 통화기록들은 동작비용이 메시지 손실의 위험량에 의해 자리 맞춤되었을 때 표면적인 영구상태지만 영구 저장소에 저장되는 것으로 처리된다.

이와 다른 애플리케이션에서는, 데이터를 잔존한 대가와 이득과 연관된 평가 기준에 근거하여 영구적으로 저장할 것인지 아닌지에 대한 결정이 모든 데이터 항목에 적용될 것이다(혹은 높은 값(다른 값들을 일시적인 것으로 취급한다)이나 낮은 값(다른 값들을 영구적인 것으로 취급한다)의 항목에만 적용될 수 있다).

1 센트 전화 비용의 예에서, 첫 번째 messageValue를 1이라고 보자. 또한 messagingProcessingRate가 초당 1000이고, 평균 timeInProcess가 0.2이며, 평균적으로 매10일마다 오류가 발생한다고 하자. 한 큐에 40개의 메시지가 추가된다고 하면,

messageValue = 1.0

messagingProcessingRate = 1000

PositionInQueue = 40

TimeToHeadOfQueue = positionInQueue / messageProcessingRate = 0.04

TimeInProcess = 0.2

TimeHeld=TimeToHeadOfQueue + timeInProcess = 0.24

meanTimeToFailure = 10 x 24 x 60 x 60 = 864000

riskOfLoss = min(1, timeHeld/ meanTimeToFailure) = 2.78e-7

riskCost = messageValue * riskOfLoss = 2.78e-7

persistenceCost가 3.17e-7 (riskCost < persistenceCost)라면, 메시지는 영구적으로 저장되지 않을 것이다.

그러나, 10 센트 전화비용은 영구적으로 저장될 것이다. 이는

riskCost = 10 * 2.78e-7 = 0.00000278 > 3.17e-7

riskCost > persistenceCost

이기 때문이다.

기존의 시스템에서, persistenceCost는 일정한 값이 아님을 알아야 한다. 예를들어, 디스크 쓰기가 버퍼(buffer)에 있는 모든 로그 기록을 위해 막 수행되려 할 때, 새 메시지를 위한 단일 로그 기록과 연관된 persistenceCost는 동시에 작성되기위해 다른 데이터들이 없을때 이루어지는 디스크 쓰기 직후의 persistenceCost와 비교해볼 때 매우 낮을 것이다.

전화비용의 예에서, 메시지를 전달하기 위한 오류의 영업비용은 통화의 대가(아마 대다수의 소비자들은 그들의 통화료의 정확한 기록을 좋아할 것이다)와 매우 근접할 수 있다. 중복된 전송의 영업비용은 보다 쉽게 양을 정할 수 있지만(대부분의 소비자들이 미부과되는 것보다 중복부과되는데 훨씬더 반발할 것이다), 외부 메시지 시스템과 닮은 시스템이 중복을 찾아내는데 쓰일 것이다(중복을 제거하 는 경우에는 영업비용보다 프로세스비용이 더 고려될 것이다). 또한, 기존의 방법들은 메시지의 불러오기/삭제기록과 되돌아온 모든 정보를 조심스럽게 제어하는 프로토콜을 이미 수행한다. 그러므로, 여기에서의 기술은 중복보다 메시지를 전달하기위한 오류의 비용과 위험에 초점을 맞추었다. 하지만 본 발명 또한 중복된 전달의 비용을 평가하는데에도 적용될 수 있다.

상기 언급된 것처럼, 메시지는 riskCost 계산에 근거한 '영속성 큐'(영구 저장소에 저장하기 위해 만들어진 항목의 큐)에 놓여질 것이다. 한 실시예에서는, 이러한 riskCost와 큐에서 각각의 메시지의 위치가 주기적으로 다시 계산되거나, 소비자 애플리케이션의 시작 혹은 중지와 같은 동작에 따라서 다시 계산될 것이다. 높은 값의 메시지는 큐의 헤드(head)로 옮겨지고 빠르게 잔존할 것이다. 반면에 작은 값 메시지는 잔존하기 전에 프로세싱되기 때문에 높은 값의 메시지에 비해 뒤늦게 잔존한다.

규칙들과 전화비용에 관한 상기예들은 데이터를 영구적으로 저장할지 아닐지를 결정하는데 적용할 여러가지 고려 사항중에 하나의 실례일 뿐이다. 다른 룰들(규칙)은 큐의 깊이, CPU 부하와 같은 통계치와 오류예측등과 같은 자료나 메시지 크기와 같은 요인들을 고려하여 특정 시스템의 영속성 병목현상이 자리맞춤을 하는지에 따라 다양한 단계들을 거쳐 실행될 것이다.

비록 이러한 규칙들의 변동이 기술에 능숙한 이들에게 일어나지만, 이는 데이터를 영구 저장소에 저장하는 이익 및 비용과 관계있는 동적인 기준의 평가에 근거하여 영구 저장소에 저장할 것인지 아닌지에 대한 결정은 영속성 특성이 미리 정 해진 기존의 방법들에서 벗어나 있다. 상기의 실시예들은 몇몇 영구 저장 동작의 생략을 가능케 하며, 로그와 메시지 큐들을 영구 저장소에 저장하기로 결정된 주변의 디스크 기억장치에 쓰는 것과 연관된 동작의 병목현상을 제거하는 것이 요구되지 않는다.

몇몇의 예시 현상들은 메시지 시스템 안에서의 융통성과 발명의 잠재적인 이익을 설명하는데 제시될 것이다. 예를들어, 메시지 큐가 동적 소비자(active 소비자)(혹은 상기 언급된 전달자에 의해)에 의해 재빨리 유출될 때, 상기 언급된 영속성의 결정은 큐에 첨부된 메시지가 영구적으로 저장될 필요가 없다는 것을 결정한다. 그러나, 소비자가 폐쇄되면(예를 들어 소비자가 사용하는 또다른 리소스의 실패가 있다면), 다른 영속성 결정이 상이한 결과와 함께 실행될 것이다. 위와 같은 공식들을 이용할 때, 큐에 남아있기 쉬운 메시지들의 증가시간은 riskOfLoss의 증가와 더 높은 riskCost(큐에서 영구적으로 메시지가 저장되도록 하는)를 가져온다. 남아있기 위한 이러한 결정이 새로 도착하는 메시지에만 적용될 수 있거나, 대기하던 모든 메시지에 소급하여 적용될 수 있다.

본 예를 설명하기 위해서, 메시징 네트워크를 생각해보자. 최초 생성자가 첫번째 메시징 관리자(QM1)을 통해서 메시지를 보내고, 두번째 메시징 관리자(QM2)로 전송하는데 전달자를 이용하며, 최종 소비자에 의해 QM2가 검색을 위해 메시지를 enqueue하게된다. 만약 기존의 메시지가 최초 생성자로부터 QM1과 QM2로 빠르게 옮겨지고 최종 소비자는 느리거나 정지하였다면, 메시지는 QM1에 잔존하는 것이 아니고 QM2에 남아있게 될 것이다. 다시말해서 메시지가 들어갔을 때 전달자가 느 리거나 정지하였다면, 메시지는 QM1에 남아있게 된다. 만약 소비자가 전달자가 최종적으로 메시지로 이동한 경우 이미 움직이고 있다면, 메시지는 QM2에 남아있지 않을 것이다.

만약 메시지가 매우 작은 값을 가진다면 양 메시징 관리자에 남아있을 필요가 없지만, 메시지가 매우 큰 값을 가진다면 메시지는 양 메시징 관리자 모두에 남아 있을 것이다. 큰 값의 메시지들은 영속성 큐의 헤드로 전달되고 잔존하기전에 프로세스되는 경향이 있는 작은 값의 메시지와 비교해서 매우 빨리 남아있게 된다.

상기 언급했듯이, 본 발명의 이러한 실시예들은 메시지 값이 메시지 API를 거쳐서 구체화된다. 이는 PERSISTENT, NON_PERSISTENT, PERSISTENCE_AS_Q_DEF중 하나로 지정되는 영속성 속성(MQMD.persistence)과 결합하는데 사용되는 메시지의 값(예를들면 새로운 메시지 헤더 영역에 놓여진 MQMD.messageValue)인 첫 번째 실시예를 포함한다. NON-PERSISTENT 메시지들은 기존의 방법으로 제어되고 다른 메시지들은 주변환경이 간과된 '표면적인 영구'상태를 자리맞춤하는지 결정하기위해 평가된다. 또 다른 실시예에서는, 메시지 시스템이 메시지 값을 차지하는 동시에 PERSISTENCE_BY_VALUE의 새로운 영속성 속성 선택을 가능하기 위해 영속성 속성(MQMD.persistence)와 연관된 메시지가 혼합된 메시지 헤더(MQMD)안의 추가 영역을 제공한다. 그 후 메시지 전송자 애플리케이션 프로그램은 'PERSISTENT' 'NON_PERSISTENT' 'PERSISTENCE_AS_Q_DEF' 'PERSISTENCE_BY_VALUE' 중의 하나로 구체화될 수 있다.

메시지 값의 영역은 센트 단위와 영역이 준비되지 않았을때 -1과 같은 값을 나타내는 디폴트(default) 값을 가진 32비트 정수(interger)나 32비트 소수점 수(floatifng point number)가 될 것이다.

또 다른 실시예에서는, 기존의 'PERSISTENCE_AS_Q_DEF' 속성 값이 가능하난 최종 소비자 애플리케이션의 입력 큐로부터 멀리까지 메시징 네트워크를 거쳐서 통과할 것이다. 이 속성값은 초기 메시징 관리자와 다른 메시징 관리자에 의해서 본 발명의 평가과 영속성의 결정을 수행함으로써 응답될 것이다.

그러나 또 다른 실시예에서는, 존재하던 영속성 속성에 메시지 값을 부가하는 대신에, API를 거쳐서 구체화된 메시지 값이 모든 메시지들의 영속성을 결정하기 위한 기초자료를 제공할 것이다.

본 발명은 위에서 설명하였듯이 애플리케이션과 시스템의 측면에서 볼때 영구 저장소 상에 기록하는 것을 막음으로써 남아있던 메시지의 오버헤드나 다른 데이터 업데이트를 줄이는 것이 바람직하다. 다른 방법은 '영구적'인 메시지 송신측의 값을 절대적인 요구값으로 다루지만, '일시적'으로 구체화된 의미있는 메시지 값을 평가된 기준이 적절하다고 결정한 영구적인 메시지에서 온 이득으로 둔다. 예를들어, 매우 높은 메시지 값은 영구적으로 제어되나, 실제 시스템 오류가 감지되거나 시스템 오류의 위험을 나타내는 경우 모든 메시지들은 한 주기 시간동안은 영구적으로 제어된다.

도 4와 도 5는 발명의 실시예에 따른 방법을 단계별로 간단히 표현한 것이다. 도 4A에 나타난 것처럼, 과정은 200을 만드는 제1 애플리케이션 프로그램(40)과 메시지 페이로드(payload)와 송신기에 대한 정보를 포함하는 메시지 헤더, 목표 메시지 메니저와 메시지 큐의 일치,속성 세트와 함께 시작된다. 제1 실시예에서, 전송자 애플리케이션은 'PERSISTENT', 'NON_PERSISTENT', 'PERSISTENCE_AS_Q_DEF'와 같은 영속성 속성중 하나를 구체화시킨다. 애플리케이션은 메시지를 로컬 메시징 관리자(30)에 의해 관리되는 메시지 큐위에 위치시키기 위해 'put_message' 명령어를 사용한다. 로컬 메시징 관리자는 목표 메시징 관리자의 확인에 기초하여(큐 혹은 분리된 큐안에서 나뉜 영역에서 큐에 위치된(enqueue) 영구/일시적인 메시지들의 영속성 속성에 기초하기도 함) 메시지가 놓여질 적절한 로컬 큐을 식별한다. 만약 로컬 큐이 원격 목표 큐로 가는 길에 있는 중간 전송 큐이라면, 로컬 메시징 관리자의 전달자 구성은 원격 메시징 관리자로 전송하기 위해 다음 순서로서(혹은 비동기적으로) 220의 메시지를 검색한다(이때 다중 중간 메시징 관리자를 거친다). 하지만, 메시지가 로컬 큐 관리자(30)에 의해 제어되는 큐에 있을 때, 로컬 영속성 관리자(80)는 메시지와 관련된 메시지와 로그 데이터가 영구 저장소에 저장되야만 하는지 230에서 결정해야 한다. 이는 주기적으로 혹은 트리거 상태에 맞추어 결정된다. 앞서 서술한 것처럼, 트리거 상태들(trigger conditions)의 예는 메시지를 큐에 위치시키거나 시스템 문제를 발견하는 것과 같은 동작, 혹은 메시지 수의 한계에 도달한 큐의 깊이 상태등을 포함한다. 만약 영속성 관리자가 영구 저장소에 저장하는 것이 필요하다고 결정한다면, 저장 작업은 240에서 즉시 이루어진다(비록 다른 실시예에서 디스크에 쓰는 명령들이 그 자체로 우선순위를 가지고 큐에 위치(enqueue)되더라도). 만약 영속성 관리자가 영구 저장소에 저장하는 것이 당장 필요치 않다고 결정한다면, 영속성 관리자는 큐에 남아있는 메시지들 의 다음 평가와 영속성 결정을 위해 세트 시간주기의 끝에 250에 타이머를 설정할 것이다. 상기에 대한 더 상세한 방법은 도 4A에 나타내었다.

도 4B는 메시지 조직 시스템이 아닌 데이터 프로세스 시스템에서 메시징 관리자와 영속성 관리자에 의해 작동되는 단계를 나타낸 것이다. 메시징 관리자는 300에서 메시지를 다른 메시징 관리자로부터 받고, 목표 메시징 관리자와 목표 큐을 식별하하고 우선순위와 구체적인 영속성을 메시지 속성에 관계시키기 위해 310에서 메시지 헤더와 메시지의 다른 데이터 영역을 읽는다. 그런 후에, 메시지는 도 4A에서 나타난 방법대로 제어되며(전달자혹은 320처럼 메시지를 검색하는 로컬 애플리케이션 프로그램과 함께), 영속성 관리자는 330에서 남겨진 메시지의 이익과 비용을 평가한다. 이어서 340에서 디스크에 쓰거나 350에서 타이머가 꺼질때까지 영속성 결정이 연기된다.

도 5는 다른 발명의 실시예에 따른 초기 메시지 시스템에서 수행되는 방법의 단계를 나타낸다. 전송자 애플리케이션 프로그램은 400에서 다시 메시지를 생성하고 목표 메시징 관리자와 큐을 일치시키는 'put_message' 명령어를 부른다. 하지만, 영속성 속성을 구체화시키는 대신, 송신기가 400에서 메시지 헤더안의 메시지 값을 구체화시킨다. 로컬 메시징 관리자(30)은 410에서 메시지 헤더를 읽고, 어떤 로컬 큐에 메시지를 위치시키고 큐를 위치시켜야(enqueue) 할지를 결정한다. 본 실시예에서, 상이한 메시지 값은 동일한 큐에 저장된다. 목표 큐가 로컬 큐 관리자에 의해 제어되지 않는다고 가정하면, 로컬 메시징 관리자안의 전달자는 곧바로 420에서 메시지를 검색하고 메시지를 목표 메시징 관리자의 길을 따라 다음 메시징 관리자로 송신한다. 영속성 결정이 메시지가 도달한 다른 메시지 시스템에서 이루어지게 하려고 메시지 값은 메시지와 함께 전송된다. 메시지가 로컬영역에 있는동안, 로컬 영속성 관리자(80)는 메시지를 로컬 영구 저장소(90)에 저장할지를 결정한다. 영속성 관리자는 큐에 있는 메시지의 헤더의 정보를 읽고 430에서 영구 저장소에 저장되는 이익과 대가를 평가한다. 위에서 서술한 것처럼, 이런 평가가 영구적으로 저장하는 이익을 평가할 때 메시지 값(주어진 메시지 값에서 손실 혹은 중복된 메시지의 영업비용, 메시지 손실의 위험과 같은)을 고려한다. 그 후에 영속성 관리자는 디스크에 쓰는 것을 시작하거나 위에서 서술된 다음 평가를 위한 타이머를 설정한다.

도 6은 데이터베이스 업데이트의 영구적인 저장을 제어하기위해 다른 실시예의 구성를 표시하는 데이터베이스 시스템을 나타낸다. 프로세서(500), 입/출력 구성(510), 휘발성 랜덤 엑세스 메모리(RAM)(520), 비휘발성 디스크 기억장치 시스템(530), 데이터베이스 관리자(540), 영속성 관리자(550)등을 포함하는 시스템의 다양한 구성들은 시스템 버스(560)를 통해서 연결되어있다. 영속성 관리자(550)는 데이터 수집기(551), 트리거 구성(552), 룰 저장소(553), 평가자 구성(554)등으로 이루어진다. 데이터베이스 관리자(540)은 RAM(520)에 있는 테이터 테이블들의 항목(570)을 관리하고, 데이터 업데이트를 데이터베이스(570)로 읽고 쓴다. 수집기 구성(551)은 RAM(520)안에서 데이터 업데이트를 탐색하고 업데이트 혹은 데이터베이스 시스템에서 두번째 데이터베이스(580)과 관련된 상태와 관련된 정보들을 저장한다. 트리거 구성(552)에 의해 확인된 트리거 상태에 반응하여, 평가자 구 성(554)는 영구 저장소에 저장하는 이익과 대가를 평가하면서 규칙 저장소(553)에서 얻어진 규칙을 두번째 데이터베이스(580)에 있는 데이터에 적용시킨다. 이러한 평가를 통해 비휘발성 데이터 창고(530)안에서 데이터베이스(570)의 영구 복사본(590)으로 데이터 업데이트를 저장할지를 결정한다. 디스크 기억장치와 같은 비휘발성 기억장치에 데이터를 쓰는것은 평가가 영구적인 저장이 필요하다고 결정한 경우에만 수행되기 때문에, 이러한 과정으로 데이터베이스 시스템이 작은 데이터 항목 값의 작은 오버헤드(그리고 잠재적으로 높은 수행 동작) 기억장치에 적합한지 알아볼 수 있다.

Claims

데이터 처리 장치에 있어서,

프로세서;

휘발성 데이터 저장소;

비휘발성 데이터 저장소; 및

상기 비휘발성 데이터 저장소로의 데이터의 저장을 관리하는 영속성 관리자(persistence manager)를 포함하며,

상기 영속성 관리자는 상기 비휘발성 데이터 저장소에 유지되는 데이터 업데이트(data update)가 상기 비휘발성 데이터 저장소로의 저장을 필요로 하는 지를 판정하기 위해 기준 세트 중에서 적어도 하나의 기준을 평가하는 수단을 포함하며, 상기 기준 세트는 상기 비휘발성 데이터 저장소로의 데이터 저장의 비용, 및 저장하지 않은 경우 이와 관련된 리스크를 나타내는, 데이터 처리 장치.
제 1 항에 있어서,

상기 평가 수단은 상기 비휘발성 데이터 저장소로의 데이터 저장 비용을 나타내는 적어도 제1 기준, 및 상기 비휘발성 데이터 저장소로 데이터를 저장하지 않는 경우 이와 관련된 리스크를 나타내는 제2 기준을 평가하는 수단; 및

상기 비용 및 리스크를 비교하여 상기 판정을 하는 수단;

을 포함하는, 데이터 처리 장치.
제 1 항 또는 제 2 항에 있어서,

상기 영속성 관리자는 상기 비휘발성 데이터 저장소로 상기 데이터 업데이트가 저장되지 않는 경우 데이터 손실 리스크를 평가하는 함수를 포함하는, 데이터 처리 장치.
제 3 항에 있어서,

상기 영속성 관리자는 상기 데이터 업데이트 값 및 상기 데이터의 손실 리스크를 토대로 하여 데이터 손실의 잠재적 비용을 계산하는 함수를 포함하는, 데이터 처리 장치.
제 1 항 내지 제 4 항 중 어느 한 항에 있어서,

상기 영속성 관리자는 상기 비휘발성 데이터 저장소로 상기 데이터 업데이트가 저장되지 않은 경우 데이터 업데이트가 중복될 리스크를 평가하는 함수를 포함하는, 데이터 처리 장치.
제 1 항에 있어서,

상기 영속성 관리자는 상기 데이터 처리 장치의 성능 특성을 평가하는 수단을 포함하는, 데이터 처리 장치.
제 1 항 내지 제 6 항 중 어느 한 항에 있어서,

메시징 관리자를 더 포함하며,

상기 영속성 관리자는 상기 메시징 관리자가 상기 메시지를 처리하는 도중에, 기준 세트 ― 상기 기준 세트는 메시지를 상기 비휘발성 데이터 저장소에 저장하는 비용, 및 메시지 관련 데이터를 상기 비휘발성 데이터 저장소에 저장하지 않는 경우 이와 관련된 리스크를 나타냄 ― 중 적어도 하나의 기준을 평가하는 함수;

상기 평가에 의해서 상기 메시지 관련 데이터를 상기 비휘발성 데이터 저장소에 저장할 지를 판정하는 함수;

상기 판정이 긍정이면, 상기 비휘발성 데이터 저장소로 상기 메시지 관련 데이터의 저장을 개시하는 함수;를 포함하는 데이터 처리 장치.
제 1 항 내지 제 4 항 중 어느 한 항에 있어서,

상기 비휘발성 데이터 저장소에 유지되는 데이터베이스 테이블에 데이터 업 데이트를 하기 위한 데이터베이스 관리자를 더 포함하며,

상기 영속성 관리자는 데이터 업데이트, 추가 및 삭제에 의해서, 상기 비휘발성 데이터 저장소로 저장이 필요하게 되는 지를 적어도 하나의 기준 평가를 토대로 하여 판정하는 함수를 구현하는, 데이터 처리 장치.
데이터 처리 장치내에서 데이터의 영속성을 관리하는 방법으로서,

기준 세트 ― 상기 기준 세트는 메시지를 상기 비휘발성 데이터 저장소에 저장하는 비용, 및 메시지 관련 데이터를 상기 비휘발성 데이터 저장소에 저장하지 않는 경우 이와 관련된 리스크를 나타냄 ― 중 적어도 하나의 기준을 평가하여 데이터 업데이트를 영구 저장소에 저장하는 지를 판정하는 단계; 및

상기 데이터 업데이트가 영구 저장소에 저장되어야 한다는 판정에 따라, 상기 영구 저장소로의 상기 업데이트의 저장을 개시하는 단계;

를 포함하는 데이터 영속성 관리 방법.
컴퓨터 프로그램을 실행시키는 데이터 처리 장치의 수행을 제어하기 위한 프로그램 코드로 구현된 명령어 세트를 포함하는, 제 9 항에 따른 데이터 영속성 관리 방법을 수행하는 컴퓨터 판독 가능 매체.