KR100317402B1

KR100317402B1 - 서버자원에대한병행억세스제어를위한임의의로킹모드를제공하기위한장치,방법및컴퓨터프로그램

Info

Publication number: KR100317402B1
Application number: KR1019980017671A
Authority: KR
Inventors: 사이먼 안토니 제임스 홀즈워스; 아이안 스튜어트 콜드웰 하우스톤
Original assignee: 포만 제프리 엘; 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 1997-06-20
Filing date: 1998-05-15
Publication date: 2002-02-19
Also published as: GB2326492A; US6044404A; GB9712930D0; KR19990006460A; GB2326492B

Abstract

본 발명의 클라이언트/서버 컴퓨팅 시스템을 위한 병행 제어 메카니즘은 현재 서버 자원에 억세스하고 있는 다른 클라이언트 요구와 함께, 서버 자원에 대한 병행 억세스가 제공될 수 있는지 판단하기 위해 각각의 클라이언트 요구를 분석한다. 각각의 클라이언트 요구는 대응하는 요구의 상세내용을 기반으로 하는 충돌 해결 로직을 포함하는 로크 요구 모드의 셋업을 일으킨다. 새로운 요구가 들어오면, 이 새로운 요구의 새로 생성된 로크 요구 모드는 서버 자원에 현재 억세스하고 있는 이전의 요구의 로크 요구 모드에 비교되고, 이 새로운 요구에도 억세스가 허용되어야 하는지 판단하기 위해 충돌 해결 로직이 실행된다.

Description

서버 자원에 대한 병행 억세스 제어를 위한 임의의 로킹 모드를 제공하기 위한 장치, 방법 및 컴퓨터 프로그램{APPARATUS, METHOD AND COMPUTER PROGRAM FOR PROVIDING ARBITRARY LOCKING MODES FOR CONTROLLING CONCURRENT ACCESS TO SERVER RESOURCES}

본 발명은 한 컴퓨팅 장치("클라이언트")가 클라이언트 작업의 일부를 수행할 것을 다른 컴퓨팅 장치("서버")에 요구하는 클라이언트/서버 컴퓨팅("분산(distributed)" 컴퓨팅으로서도 알려져 있음) 시스템 분야에 관한 것이다.

클라이언트/서버 컴퓨팅은 정보 기술 세계에서 지난 수년간에 걸쳐 점점 더 중요하게 되었다. 이러한 형태의 분산 컴퓨팅은, 한 머신이 그 작업의 일부를, 예를 들어, 그 작업을 수행하기에 더욱 적합할 수도 있는 다른 머신으로 위임할 수 있도록 허용한다. 예를 들어, 서버는 막대한 양의 데이터의 저장을 유지관리하는데이터베이스 프로그램을 실행하는 고성능 컴퓨터가 될 수 있으며, 클라이언트는 그 로컬 프로그램에 사용하기 위해 데이터베이스로부터 정보를 요구하는 단순한 데스크탑 개인용 컴퓨터(PC)가 될 수 있다.

클라이언트/서버 컴퓨팅의 잇점은 클라이언트와 서버가 상이한 (이종(heterogeneous)) "플랫폼"에 위치될 수 있도록 허용하는, 소위 객체-지향 프로그래밍(OOP)으로 불리는 공지된 컴퓨터 프로그래밍 기술을 이용함으로써 더욱 향상되었다. 플랫폼은 머신이 그 작업을 수행하기 위해 이용하는, 특정 하드웨어/소프트웨어/운영체제/통신 프로토콜의 조합이다. OOP는 클라이언트 애플리케이션의 작업 요구가 어떻게 통신되어 서버 애플리케이션에 의해 수용될 것인가에 관해 걱정하지 않고 클라이언트 애플리케이션 프로그램 및 서버 애플리케이션 프로그램이 그 자체의 플랫폼 상에서 동작할 수 있도록 허용한다. 마찬가지로, 서버 애플리케이션은 OOP 시스템이 어떻게 그 요구를 수신하고, 변환하고, 서버 애플리케이션의 처리 결과를 다시 요구한 클라이언트 애플리케이션으로 전송할 것인가에 관해 걱정하지 않는다.

OOP 기술이 어떻게 이종 클라이언트/서버 시스템과 통합되었는지에 관한 세부사항은 미국 특허 제 5,440,744 호 및 유럽 특허원 제 EP 0 677,943 A2 호에 설명되어 있다. 이들 2개의 공보는 본 명세서에 참조로서 병합되어 있다. 그러나, 본 발명의 환경의 문맥상의 이해를 위해 그 기본 구조의 예에 대해서는 후술하도록 한다.

도1에 도시된 바와 같이, 클라이언트 컴퓨터(10)(예를 들어, IBM OS/2 운영체제가 설치되어 있는 개인용 컴퓨터가 될 수 있음)는 그 운영체제 상에서 실행되는 애플리케이션 프로그램(40)을 구비하고 있다("IBM" 및 "OS/2"는 인터내셔널 비지네스 머신즈 코포레이션의 상표임). 애플리케이션 프로그램(40)은 서버 컴퓨터(20) 상에서 수행될 작업 및/또는 그 애플리케이션 프로그램(40)에 의한 후속 이용을 위해 서버(20)로부터 반송될 데이터를 주기적으로 필요로하게 된다. 서버 컴퓨터(20)는 예를 들어, IBM의 MVS 운영체제 상에서 실행되는 고성능 메인프레임 컴퓨터가 될 수 있다(MVS는 IBM사의 상표임). 본 발명의 목적상, 서버에 의해 수행될 통신 서비스에 대한 요구가 제1 애플리케이션 프로그램(40)과의 사용자 대화(interaction)에 의해 유발되는지 여부, 또는 애플리케이션 프로그램(40)이 사용자 대화에 무관하게 동작하고 프로그램 실행 중에 자동적으로 요구를 하는지 여부는 관계가 없다.

클라이언트 컴퓨터(10)가 서버 컴퓨터(20)의 서비스에 대한 요구를 하길 원하면, 제1 애플리케이션 프로그램(40)은 필요한 서비스를 제1 로직 수단(50)에 통지한다. 이것은 예를 들어, 입력 및 출력 파라미터의 리스트와 함께 원격 프러시져(remote procedures)의 명칭을 제1 로직 수단으로 전송함으로써 수행될 수 있다. 다음에, 제1 로직 수단(50)은 기억장치(60)에 저장된 이용가능한 통신 서비스의 정의를 참조하여 제2 컴퓨터(20)와의 필요한 통신을 설정하는 태스크를 처리한다. 가능한 모든 서비스는 객체 클래스의 결합(cohesive) 프레임워크(70)로서 정의되며, 이들 클래스는 단일 객체 클래스로부터 파생된다. 이러한 방식으로 서비스를 정의하는 것은 성능 및 재사용가능성에 관해 상당히 많은 장점을 발생시킨다.

서버(20)와의 필요한 통신을 설정하기 위해, 제1 로직 수단(50)은 프레임워크 내의 객체 클래스가 사용될 필요가 있는지 판단하고, 서버에서 그 객체의 인스턴스(instance)를 생성하며, 그 객체로 하여금 그 메쏘드(methods) 중 하나를 호출하도록 하기 위해 그 객체로 메시지가 전송된다. 이것은 접속 수단(80)을 통한 서버 컴퓨터(20)와의 접속의 설정 및 제2 로직 수단(90)으로의 후속 요구 전송을 발생시킨다.

다음에, 제2 로직 수단(90)은 서버 컴퓨터(20) 상에서 실행되는 제2 애플리케이션 프로그램(100)(이후, 서비스 애플리케이션으로 언급됨)으로 요구를 전달하고, 서비스 애플리케이션(100)은 데이터 검색 프러시져를 실행하는 것과 같은, 그 요구에 의해 필요로되는 특정 태스크를 수행할 수 있다. 일단 이 태스크가 완료되면, 서비스 애플리케이션은 그 결과를 다시 제1 컴퓨터(10)로 전송할 필요가 있을 수 있다. 서비스 애플리케이션(100)은 요구된 태스크의 수행중에 제1 컴퓨터(10)로 결과가 반송되어야 할 때 제2 로직 수단(90)과 대화한다. 제2 로직 수단(90)은 객체의 인스턴스를 설정하고, 서버 애플리케이션(100)에 의해 필요로될 때 이들 객체의 적절한 절차를 호출하게 되는데, 이들 객체 인스턴스는 기억장치(110)에 저장된 객체 클래스의 결합 프레임워크로부터 생성된다.

전술한 기술을 이용하면, 클라이언트 애플리케이션 프로그램(40)은 통신 아키텍처에 노출되지 않는다. 또한, 서비스 애플리케이션(100)은 그 환경에 있어서 표준 메카니즘을 통해 호출되며, 그것이 원격으로 호출되는지 알지 못한다.

객체 관리 그룹(Object Management Group:OMG)은 도1에 도시된 바와 같이 분산 객체를 가진 이종 플랫폼 상의 클라이언트/서버 컴퓨팅의 다양한 양상에 관계된 기구의 국제 협의체(consortium)이다. OMG는 클라이언트 컴퓨터(예,10)가 서버 컴퓨터(예, 20)와 (OOP 형태로) 통신할 수 있도록 하는 표준을 발행해 왔다. 이들 표준의 일부로서, 클라이언트 머신과 서버 머신 사이에 객체-지향 브릿지를 제공하는 객체 요구 브로커(Object Request Broker:ORB)(CORBA:Common Object Request Broker Architecture로 불림)가 정의되어 있다. ORB는 객체 지향 구현 세부사항(details)으로부터 클라이언트 및 서버 애플리케이션을 분리하며, 접속 수단(80) 뿐만 아니라 제1 및 제2 로직 수단(50, 90)의 작업의 적어도 일부를 수행한다. ORB는 또한, 서비스 애플리케이션(100)의 다양한 서버 객체 사이의 모든 대화를 처리한다.

여러 가지 산업에서의 매우 중요한 비지니스 태스크를 위해 컴퓨터 구현 트랜잭션 처리 시스템이 사용된다. 트랜잭션은 완전히 완료되거나 또는 아무런 동작 없이 완전히 일소(purge)되어야 하는 단일 작업 단위를 정의한다. 예를 들어, 고객이 돈을 회수하려고 하는 은행 자동화 텔러 머신(ATM)의 경우에, 돈을 지급하고, 머신의 잔고를 감소시키고, 고객의 은행예금 잔고를 감소시키는 동작이 모두 이루어지거나 또는 이들 동작 중 어느 것도 이루어져서는 안된다. 종속적인 동작 중 한 동작이라도 실패하면, 기록과 실제 사건 사이에 불일치를 유발하게 된다.

분산 트랜잭션 처리는 하나 이상의 물리적 또는 논리적인 위치에 있는 자원에 영향을 주는 트랜잭션을 수반한다. 전술한 예에서, 트랜잭션은 지역 자동화 텔러 머신에서 관리되는 자원뿐만 아니라 은행의 메인 컴퓨터에 의해 관리되는 은행잔고에도 영향을 준다. 이와 같은 트랜잭션은 한 특정 클라이언트 컴퓨터(예, 10)가 하나의 특정 서버 컴퓨터(예, 20)와 통신하는 것을 수반하는데, 클라이언트의 일련의 요구는 서버에 의해 처리된다.

통상적인 클라이언트/서버 시스템에서, 클라이언트 시스템 및 서버 시스템은 이와 같은 트랜잭션의 전반적인 처리에 각각 기여한다. 또한, 많은 상이한 클라이언트가 독립된 트랜잭션에 착수하기 위해 동시에 동일한 서버를 이용하기 위해 시도할 수도 있다. 예를 들어, 많은 은행 ATM 머신(클라이언트 시스템)이 은행의 대형 중앙 서버에서 실행되는 대중적인 데이터베이스 프로그램으로부터 데이터를 억세스하기 위해 동시에 트랜잭션을 시작하려고 시도할 수도 있다. 또한, 독립된 (병행) 트랜잭션의 일부가 될 수도 있는 훨씬 많은 상이한 서버내 요구(intra-server requests)(즉, 한 서버 객체로부터 다른 서버 객체로 전달되는 요구)가 존재한다. 이러한 상황에서, 서버는 이들 병행 트랜잭션을 격리하여 서로 영향을 미치지 못하도록 할 수 있어야 한다. 즉, 한 트랜잭션이 종료될 때까지(모든 부분이 완료되거나 또는 모든 부분이 중단될 때까지), 동일한 서버 객체에 억세스하기 위해 시도하는 다른 트랜잭션은 대기하도록 만들어져야 된다. 트랜잭션에 수반되는 서버 객체는 그 트랜잭션이 보류(pending)중인 동안 로크(lock)되어야 한다. 이러한 로킹은 현재의 트랜잭션에 영향을 주는, 서버 객체에 대한 트랜잭션 범위 밖의 병행 억세스를 방지한다.

예를 들어, 만일 남편은 시내의 한 쪽에 있는 한 은행의 ATM 머신에서 가족의 당좌 예금 계좌로부터 가족의 보다 높은 이자를 받는 저축 계좌로 2000 달러를대체하려고 시도하고, 그의 부인은 시내의 다른쪽에 있는 (다른 은행이 소유한) 다른 ATM에서 동일한 기능을 수행하기 위해 시도하는 경우에, 서버는 이들 2개의 병행 트랜잭션이 데이터베이스 서버를 소유한 은행에 대해 문제를 발생하지 않도록 이러한 상황에 효과적으로 대처해야 한다.

이러한 문제가 통상적으로 객체 지향 프로그래밍과 관련하여 해결되었던 방법은 서버 데이터베이스 프로그램(서버 또는 서비스 애플리케이션 프로그램 100)이 그 프로그램의 본질적인 기능을 수행할 뿐만 아니라 병행 억세스에 대한 트랜잭션의 로킹을 수행하도록 작성되는 것이다. 즉, 서버 애플리케이션(100)은 일단 제1 클라이언트(예, 남편의 ATM)가 억세스를 요구하면 데이터베이스에 저장된 그 가족의 계좌에 대한 억세스를 로킹하도록 작성되게 된다. 그러면, 남편의 트랜잭션은 부인의 트랜잭션이 동시에 요구되었다는 사실에도 불구하고 격리되어 계속되게 된다. 부인의 클라이언트 ATM은 데이터에 대한 억세스가 허가되지 않게 되는데, 그 이유는 남편의 클라이언트 ATM이 그 데이터를 캡슐화하고 있는 객체에 대해 이미 로킹했기 때문이다.

현재 이와 같은 병행 제어가 수행되는 방법은 다음과 같다. 서버에 도달하는 클라이언트로부터의 각각의 요구는 먼저 병행 제어 게이트웨이(concurrency control gateway)를 통해 통과되며, 이 게이트웨이는 그 요구를 분석하고, 그것을 서버 자원에 대한 억세스가 이미 허가되어 아직도 그 자원에 실제적으로 억세스하고 있는 요구와 비교한다. 이러한 비교의 목적은 새로운 요구가 이전의 (또한 여전히 수행되고 있는) 요구와 양립할 수 있는지 판단하기 위한 것이다. 만일 그렇다면, 새로운 요구는 병행 제어 게이트웨이를 통과하도록 허용될 수 있다. 만일 그렇지 않다면, 이 새로운 요구는 이전의 요구중 적어도 하나가 종료될 때까지 대기해야 한다.

한 클라이언트가 특정 당좌 예금 계좌의 잔고에 현금을 추가하기 위한 요구를 발생했다고 가정하자(당좌 예금 계좌는 서버에서 당좌 예금 계좌 객체에 의해 표현된다). 또한, 그 특정 당좌 예금 계좌 객체에 억세스하기 위해 시도한 다른 클라이언트 요구는 없다고 가정하자. 서버 소프트웨어는 이 요구를 수신하고, 그것을 분석하여, 그에 수반되는 연산(잔고에 현금을 추가하는 연산)으로부터, 이 요구가 당좌 예금 계좌 객체에 대한 "기록 억세스(write access)"를 필요로 한다고 판단한다(그 이유는 추가하는 연산은 잔고를 증가시키기 위해 당좌 예금 계좌 객체의 상태가 변경될 것을 필요로 하기 때문이다). 이 객체에 억세스하기 위해 시도한 다른 요구는 없기 때문에, 다른 요구에 관한 동시 발생 문제는 없으며, 따라서 이 요구는 단순히 그 요구의 실행을 위해 목표 객체로 전송된다.

이제, 이 요구가 목표 객체에 억세스하는 동안, 다른 클라이언트가 동일한 당좌 예금 계좌 객체의 계정 잔고를 확인하기 위해 병행 요구를 한다고 가정하자. 그러면, 서버 소프트웨어는 그에 수반되는 연산(은행 잔고 확인)으로부터 이 요구가 목표 객체에 대한 "판독 억세스(read access)"를 필요로 한다고 판단한다. 다음에, 서버 소프트웨어는 이미 "기록 억세스"를 한 다른 요구와 동시에 목표 객체에 대한 억세스가 이 새로운 요구에 제공될 수 있는지 판단하기 위해 테이블을 검사한다. 이 테이블은 적은 수의 (통상적으로는 약 5개의) 억세스 모드(판독 억세스, 기록 억세스 등)의 각각의 조합에 대한 예/아니오 스칼라값(scalarvalues)을 저장하고 있다.

본 예에서, 이 새로운 요구는 테이블로부터 이전의 요구와 충돌(conflict)하는 것으로 발견되게 되는데, 그 이유는 "판독 억세스" 요구는 "기록 억세스" 요구가 기록을 종료할 때까지 대기해야 하며, 그렇지 않으면, 이 "판독 억세스" 요구가 데이터를 판독할 때 "기록 억세스" 요구가 실제적으로 데이터를 변경했는지 여부에 따라 이 "판독 억세스" 요구에 상이한 결과가 제공되기 때문이다. 이것을 피하기 위해, "판독 억세스" 요구는 "기록 억세스"가 완전히 종료되어 목표 객체에 더 이상 억세스하지 않을 때까지 대기하도록 되어 있다("기록 억세스" 요구는 목표 객체에 대한 "기록 로크"를 갖는다고 말한다).

그러므로, 종래 기술에서의 병행 요구 사이의 충돌은 전통적으로, 새로운 클라이언트 요구(예, "잔고 확인")를 검사하고, 이 요구를 적은 수(예, 5개)의 억세스 모드(예, 판독)중 한 모드로 변환하고, 이 억세스 모드를 이전의 (또한 여전히 수행되고 있는) 요구의 억세스 모드와 비교하는 병행 제어 게이트웨이에 의해 판단이 이루어진다. 요구와 관련된 연산(예, "잔고 확인")이 단순하고 오직 하나의 억세스 모드(예, 판독)에 대응하는 경우에는 이러한 병행 제어 기술로 충분하다.

그러나, 연산과 억세스 모드 사이의 관계가 단순한 1 대 1 대응이 아닌 상황이 존재한다. 또한, 데드록(deadlock)(어떤 요구가 현재 홀드하고 있는 서버 자원에 억세스하기 위해 2개의 요구가 각각 대기하고 있는 경우임)의 감소 및/또는 보다 큰 효율성을 실현하기 위해 이 관계가 보다 복잡하게 이루어질 수 있는 상황이존재한다. 예를 들어, 목표 객체가 복합적일 때(그것이 다른 객체를 포함하거나 참조할 때) 충돌 해결이 복잡해지며, 또한 병행 제어를 위한 전술한 종래의 접근방법이 사용될 때에는, 한 요구가 단지 객체의 부분집합에 대한 배타적인 억세스를 필요로 하는 경우에도 객체 그룹 전체에 대한 배타적인 억세스를 그 요구에 허가하는 것과 같은 덜 바람직한 절충 결과를 초래한다.

몇몇 종래 기술은 단지 적은 수(예, 5개)의 억세스 모드를 이용한 로킹과 관련된 문제를 주목했으며, 따라서, 연산이 보다 큰 셋트의 억세스 모드로 매핑되도도록 사전정의된(predefined) 로킹 모드의 수를 확장했다. 예를 들어, IEEE Transactions on Software Engineering(1985년 6월, 521-2 페이지)의 A.Z. Spector 등의 "Support for Distributed Transactions in the TABS Prototype"을 참조하라.

그러나, 이 후자의 종래 기술은 억세스 모드 셋트가 크기는 하지만, 여전히 사전정의된 억세스 모드에 의해 동작한다. 연산과 억세스 모드 사이의 매핑은 미리 결정되며, 충돌 검사는 여전히 억세스 모드를 비교함으로써 수행된다. 이러한 이유로 인해, 특히 복합적인(compound) 객체에 의해 표현되는 서버 자원의 경우에, 여전히 특정의 로크 리퀘스터(requester)에게 서버 자원에 대한 필요한 배타적 억세스보다 더 과도한 배타적 억세스가 제공된다.

복합적인 객체와 관련된 것과 같은 보다 더 복잡한 서버 자원에서, 충돌 해결은 이상적으로는 다수의 요인에 근거하여 수행되어야 한다. 예를 들어, 큐 객체(queue object)는 (독립된 객체로서 각각 표현되는) 6개의 구성요소(elements)를 포함한다. 큐 객체는 그것이 6개의 구성요소를 포함하기 때문에 공백 상태가 아니다. 제1 클라이언트 요구는 제1 구성요소를 제거하는 것이고, 제2 클라이언트 요구는 다른 (제7) 구성요소를 추가하는 것이다. 각각의 요구는 큐 객체의 무결성(integrity)을 절충하지 않고 독립된 트랜잭션 하에서 동시에 실행될 수 있다. 억세스를 허가하는 것은 (a) 큐 객체의 항상 변화되는 상태(이 경우에는, 그것이 공백인지 여부) 및 (b) 2개의 요구의 세부사항(details)에 의존한다. 만일 큐가 공백 상태이면, 그 요구 자체가 본래부터 충돌하지 않는 것이라 할지라도 두 요구 모두에 병행 억세스가 제공될 수 없는데, 그 이유는, 만일 큐가 공백 상태인 경우에 구성요소를 제거하기 위한 요구가 발생될 수 없기 때문이다.

두 번째 예는 (포함하는 어레이 객체 내에 포함된 객체와 같이 다수의 구성요소를 포함하는) 비-공백(non-empty) 어레이 객체이다. 제1 요구는 어레이의 기존의 구성요소를 갱신하는 것이고, 제2 요구는 다른 기존의 구성요소를 삭제하는 것이다. 제3 요구는 구성요소가 존재하지 않는 어레이내의 위치에 구성요소를 추가하는 것이다. 그리고, 제4 요구는, 존재는 하지만 제1 요구의 목표도 제2의 요구의 목표도 아닌 어레이 구성요소를 삭제하는 것이다. 이들 각각의 요구는 어레이의 무결성 또는 다른 3개의 트랜잭션 각각에서 수행되는 작업을 절충하지 않고, 그 자신의 트랜잭션 하에서 동시에 실행될 수 있다. 또한, 각각의 요구에 대해 억세스를 허가하는 것은 다른 3개의 요구와 관련하여 그 요구의 세부사항 및 어레이 객체의 상태에 의존한다.

단지 사전정의된 억세스 모드를 비교함으로써 운영되는 전술한 종래의 충돌 해결 기술은 이와 같은 요인들의 수집을 고려할 수 없으며, 따라서 바람직하지 못한 병행 제어 결과를 유발할 수 있다.

본 발명의 제1 관점에 따르면, 본 발명은 클라이언트가 서버 자원에 대한 억세스를 위해 서버에 요구를 전송하는 클라이언트/서버 컴퓨팅 시스템에 사용하기 위한 병행 제어 장치를 제공한다. 이 장치는, 제1 클라이언트 요구를 수신하고, 상기 제1 요구의 수신에 응답하여 상기 수신된 제1 요구를 기반으로 하는 충돌 해결 로직을 포함하는 제1 로크 요구 모드를 셋업하기 위한 수단; 제2 클라이언트 요구를 수신하고, 상기 제2 클라이언트 요구의 수신에 응답하여 제2 로크 요구 모드를 셋업하기 위한 수단; 및 상기 제1 및 제2 요구에 서버 자원에 대한 병행 억세스가 제공되어야 하는지 판단하기 위해 상기 제1 로크 요구 모드에 포함된 상기 충돌 해결 로직을 이용하여 상기 제1 및 제2 로크 요구 모드를 비교하기 위한 수단을 포함한다.

바람직하게는, 상기 제2 로크 요구 모드는 상기 제2 수신 요구를 기반으로 하는 충돌 해결 로직을 포함한다. 또한 바람직하게는, 상기 제2 로크 요구 모드의 상기 충돌 해결 로직은 상기 제1 로크 요구 모드를 기반으로 한다. 바람직하게는, 상기 충돌 해결 로직은 또한, 클라이언트 요구가 억세스를 요구하고 있는 서버 자원의 상태를 기반으로 한다.

본 발명의 제2 관점에 따르면, 본 발명은 클라이언트/서버 컴퓨팅 시스템에서 병행 제어를 수행하기 위한 방법을 제공하며, 이 방법은 제1 관점에 대해 전술한 단계를 포함한다.

본 발명의 제3 관점에 따르면, 본 발명은, 컴퓨터 판독가능 매체 상에 저장되어, 클라이언트/서버 컴퓨팅 시스템에서 병행 제어를 수행하기 위한 컴퓨터 프로그램 제품을 제공하며, 이 컴퓨터 프로그램 제품은 제1 관점에 대해 전술한 기능을 수행하기 위한 코드 부분을 포함한다.

그러므로, 본 발명에 의하면, 현재 요구의 로크 요구 모드에 대하여 새로운 요구의 로크 요구 모드를 검사함으로써 충돌 해결이 결정되고, 이렇게 함으로써 보다 양호한 병행 제어 결과를 얻는다. 특히, 로크 요구 모드들을 비교함으로써, 본 발명의 병행 제어 메카니즘은 요구가 필요로 하는 억세스 모드의 형태 이상의 것을 고려할 수 있다. 예를 들어, 요구에 포함된 파라미터 및 목표 객체에 관한 정보(예, 그 객체의 상태)가 충돌 해결 동안에 고려될 요인으로서 포함될 수 있다.

도1은 본 발명의 양호한 실시예가 적용될 수 있는 것과 관련하여, 객체 기술을 이용한 공지된 이종 클라이언트/서버 아키텍처의 블록도.

도2는 본 발명의 양호한 실시예에 따른 클라이언트/서버 아키텍처의 블록도.

도3은 본 발명의 양호한 실시예에 따라, 병행 제어를 수행하기 위해 서버에서 행해지는 단계를 도시하는 흐름도.

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

10:클라이언트 컴퓨터

20:서버 컴퓨터

30:인터페이스

40:제1 애플리케이션 프로그램

50:제1 로직 수단

60:기억장치

70:객체 클래스의 프레임워크

80:접속 수단

90:제2 로직 수단

100:제2 애플리케이션 프로그램

110:기억장치

120:객체 클래스의 프레임워크

201a-201d:클라이언트

203:목표 객체(target object)

204:병행 제어 유닛

205a-205d:요구

본 발명은 첨부 도면을 참조한 다음의 양호한 실시예의 상세한 설명에 의해 잘 이해될 것이다.

본 발명의 제1 실시예에 따르면, 도2의 서버(202)는 다수의 클라이언트(201a,201b,201c,201d)로부터 OMG CORBA 규격(specification)에 따라 구성된 클라이언트 요구를 수신한다. 이 서버(202)는 클라이언트가 그것으로부터 정보를 얻거나 그 안의 정보를 변경 또는 추가하기 위해 요구를 전송할 수도 있는 서버 자원과 관련된 목표 객체(203)를 유지관리한다. 목표 객체(203)는 예를 들어, 다수의 구성요소(203p,203q,203r)를 포함하는 어레이 객체가 될 수도 있으며, 이들 구성요소는 어레이 객체(203)[콘테이너(container) 또는 복합(compound) 객체로서알려짐]에 의해 포함된 객체이다.

클라이언트 요구에 대해 목표 객체에 대한 억세스가 허용되기 전에, 각각의 요구는 병행 제어 유닛(204)을 통해 통과해야 하는데, 이 유닛은 현재의 요구에 대해 즉시 목표 객체(203)에 대한 억세스가 허용되어야 하는지, 또는 이전의 (또한 아직도 수행되고 있는) 요구가 목표 객체(203)에 억세스하는 것을 종료할 때까지 대기해야 하는지에 관해 판단한다. 본 실시예에서, 제어 유닛(204)은 객체 트랜잭션 서비스(OTS)를 위한 OMG의 CORBA 사양과 호환성 있는 객체 병행 제어 서비스(OCCS)로서 구현된다. 예를 들어, OMG Document 94.8.4.의 "CORBA Object Transaction Service Specification 1.0" 및 OMG TC Document 94.5.8.의 "Concurrency Control Service Proposal"을 참조하라.

4개의 클라이언트(201a-201d)가 독립된 트랜잭션 하에서 각각 실행되고 있다. 제1 클라이언트(201a)가 구성요소(203p)를 갱신하기 위해 어레이 객체(203)에 억세스하기 위한 제1 요구(205a)를 발생하면, 이 요구는 그 요구에 어레이 객체(203)에 대한 억세스가 제공될 수 있는지 판단하기 위해 병행 제어 유닛(204)에 의해 처리된다. 본 예에서는, 객체(203)에 억세스하기 위해 시도한 이전의 클라이언트 요구가 없다고 가정하면, 이 요구(205a)는 그 원하는 억세스 모드로 억세스를 허가받는다. 즉, 이 요구(205a)는 병행 제어 유닛(204)을 통과하도록 허용되며 구성요소(203p)에 대한 갱신을 수행한다. 또한, 병행 제어 유닛(204)은 그 유닛(204) 내에 포함된 로크 홀더 객체 셋트(207)에 로크 요구 모드 객체(207a)를 추가한다. 로크 요구 모드 객체(207a)는 이 요구(205a)의 세부사항을 포함한다.

다음에, 제2 클라이언트(201b)가 병행 무관성(예를 들어, 상이한 트랜잭션으로부터의) 요구(205b)를 발생하면, 이 요구(205b)도 역시 병행 제어를 위해 병행 제어 유닛(204)으로 전송된다. 이제는, 요구(205a)가 이미 어레이 객체(203)에 억세스하였기 때문에, 제2 요구(205b)에도 억세스가 제공될 수 있는지(또는, 이와 달리, 제1 요구(205a)가 객체(203)에 대한 억세스를 종료할 때까지 대기해야 하는지) 판단하기 위해 충돌 해결 프러시져가 수행되어야 한다.

병행 제어 유닛(204)은 어레이(203)의 로크 홀더 객체 셋트가 로크 모드 객체(207a)를 포함하고 있다는 것을 검출한다. 다음에, 제어 유닛(204)은 요구(205b)로부터 로크 요구 모드 객체(207b)를 생성하고, 파라미터로서 로크 요구 모드 객체(207b)를 전달하는 "양립가능 모드인가(is_compatible_mode)" 라는 메쏘드를 객체(207a) 상에서 호출한다. 다음에, 로크 요구 모드 객체(207a)는 미리 작성되어 그 안에 캡슐화된 특정 소프트웨어 코드에 근거하여 충돌 해결 프러시져를 수행한다. 로크 요구 모드 객체(207a)는 2개의 모드(207a,207b)가 서로 양립할 수 있다고 판단하는 경우에 응답 "예:양립가능 모드"를 반송한다. 다음에, 제어 유닛(204)은 요구(205b)가 어레이 객체(203)에 억세스[및 특히, 구성요소(203q)를 갱신]할 수 있도록 허용하고, 로크 홀더 셋트(207)에 로크 요구 모드 객체(207b)를 추가한다.

본 예에서는 충돌이 발생하지 않기 때문에, 요구(205c, 205d) 각각에 대해서도 이와 비슷한 패턴이 반복된다. 특정하여 말하면, 클라이언트(201c)로부터 요구(205c)를 수신하면, 제어 유닛(204)은 요구(205c)로부터 로크 요구 모드(207c)를 생성하고, 각각의 2개의 절차에서 파라미터로서 로크 요구 모드(207c)를 전달하는, "양립가능 모드인가(is_compatible_mode)" 라는 메쏘드(method)를 각각의 객체(207a,207b) 상에서 호출한다. 본 예에서, 각각의 객체(207a,207b)는 "예:양립가능 모드" 응답을 반송하는데, 그 이유는 어레이 객체(203)에 새로운 구성요소(203n)를 추가하기 위한 요구(205c)는 병행 요구(205a,205b)(어레이의 다른 구성요소를 갱신하기 위한 요구)에 의해 요구되는 작업에 영향을 주지 않기 때문이다. 다음에, 클라이언트(201d)로부터 요구(205d)를 수신하면, 제어 유닛(204)은 요구(205d)로부터 로크 요구 모드(207d)를 생성하고, 각각의 3개의 메쏘드에서 파라미터로서 로크 요구 모드(207d)를 전달하는, "양립가능 모드인가(is_compatible_mode)" 라는 메쏘드를 각각의 객체(207a,207b,207c) 상에서 호출한다. 본 예에서, 각각의 객체(207a,207b,207c)는 "예:양립가능 모드" 응답을 반송하는데, 그 이유는 어레이 객체(203)로부터 구성요소(203r)를 삭제하기 위한 요구(205d)는 병행 요구(205a,205b)(어레이의 다른 구성요소를 갱신하기 위한 요구), 또는 요구(205c)[어레이(203)에 이전에 존재하지 않던 구성요소의 추가를 위한 요구]에 의해 요구되는 작업에 영향을 주지 않기 때문이다.

만일 요구(205d)가 구성요소(203r) 대신에, 구성요소(203q)의 삭제를 요구하면, 충돌이 존재하게 되는데, 그 이유는 이전의 요구(205b)가 이미 어레이 객체(203)의 구성요소(203q)에 억세스하고 있기 때문이다. 따라서, 객체(207b)에 의해 "양립가능 모드인가" 라는 절차가 수신될 때, 객체(207b)의 응답은 모드(207b,207d)는 양립 불가능하다 라는 것이 된다. 이 경우에, 요구(205d)에 대해서는 병행 제어 유닛(204)의 통과가 허용되지 않게 된다[그러나, 그 로크 모드객체(207d)는 여전히 로크 셋트(207)에 추가되게 됨]. 클라이언트(201d)는 요구(205b)가 어레이 객체(203)에 대한 그 처리를 종료할 때까지 대기 상태를 유지한다. 병행 제어 유닛(204)은 요구(205d)를 통과하도록 해도 좋은지 판단하기 위해 로크 모드 객체(207a,207b,207c) 상으로 [모드(207d) 객체 세부사항을 파라미터로서 전달하는] "양립가능 모드인가" 라는 메쏘드를 주기적으로 호출하게 된다. 이와 달리, 제어 유닛(204)은 [클라이언트(201d)가 대기하도록 되어 있지 않은 상황에서] 클라이언트(201d)에게 거부 응답을 반송할 수도 있다.

새로운 요구를 수신하면(도3의 단계 301), 서버는 먼저 병행 제어 유닛(204)이 그 셋트(207)내에 어떤 로크 요구 모드 객체를 포함하고 있는지 검사한다(단계 302). 만일 포함하고 있지 않으면, 이것은 목표 객체(203)에 대한 억세스가 제공된 이전의 요구가 없다는 것을 의미하고, 따라서 처리해야할 병행 문제가 없으며, 이 새로운 요구는 단순히 목표 객체(203) 상에서의 실행을 위해 스케쥴링된다(단계 306).

그러나, 만일 셋트(207) 내에 로그 요구 모드 객체가 존재하면, 서버 소프트웨어는 이 새로운 요구의 로크 요구 모드를 현재 셋트(207) 내에 존재하는 각각의 로크 모드 객체와 비교한다(단계 303). 셋트(207) 내의 로크 모드 객체는 이미 목표 객체(203)에 대해 억세스가 허가된 이전의 요구를 나타낸다. 새로운 요구는 이들 이전의 요구중 어느 것과도 충돌하지 않아야 하기 때문에, 셋트(207) 내의 각각의 로크 모드 객체가 검사되어야 한다.

단계(304)에서 충돌이 있는지 판단하는 데 있어서, 새로운 요구는 셋트(207)내의 각각의 로크 요구 모드 객체에 대한 메쏘드 호출을 일으킨다. 로크 요구 모드 객체는 각각의 모드와 관련된 정보를 저장하고 있기 때문에, 이들 객체는 충돌을 판단하기 위한 최상의 위치에 있다. 모드 클래스(이 클래스의 각각의 로크 요구 모드 객체는 인스턴스임)는 그 클래스의 어떤 인스턴스 상에서도 호출될 수 있는, "양립가능 모드인가" 라는 메쏘드를 포함한다. 이 메쏘드가 한 인스턴스상에서 그렇게 호출되면, 이 인스턴스는, 그 새로운 요구에 대해 목표 객체(203)에 대한 병행 억세스가 허용되어야 하는지에 관해 판단하기 위해, 새로운 요구와 함께 전달된 파라미터를 이용하고 목표 객체(203)의 상태를 고려하여 그 내부 로직을 수행한다.

만일 단계(304)에서 충돌이 없는 것으로 발견되면, 이 새로운 요구는 실행을 위해 스케쥴링된다(단계 306). 그러나, 만일 단계(304)에서 충돌이 검출되면, 이 새로운 요구는 더 이상 충돌이 없게될 때까지 대기하고 있다가(단계 305), 다음에, 스케쥴링된다(단계 306).

따라서, 각각의 로크 요구 모드는 다른 로크 모드가 그와 양립할 수 있는지 판단하기 위한 자신의 고유의 로직을 캡슐화하고 있는 객체로서 작성된다. 이 로직은 예를 들어, 객체의 인스턴스화를 일으키는 대응 요구의 특성에 적합하도록 정밀하게 맞추어서 만들어 질 수 있다. 그러므로, 클라이언트 요구에 의해 요구되는 연산의 시만틱스(semantics)가 (객체가 복수의 구성요소로 이루어진 전술한 어레이 객체 예에서와 같이) 복합적이면, 이와 같은 시만틱스의 세부사항은 로크 요구 모드 객체(207a-207d)에 의해 캡슐화되는 병행 제어 로직를 설계할 때 고려될 수 있다. 이렇게 함으로써, 복합적인 시만틱스를 가진 이와 같은 연산이 충돌 해결 동안에 비교되는 적은 수의 (예를 들어, 5개의) 억세스 모드 중 하나와 정합되도록 시도는 경우에 종래 기술에서 부딪히게 되는 불필요한 격리 문제(예컨대, 필요한 것 보다 더 큰 범위의 로크를 획득하는 것과 같은 문제)를 피할 수 있다.

이 로직은 또한 병행 제어 유닛(204)이 보호하고 있는 객체(203)의 상태에 관한 정보를 포함할 수 있다. 예를 들어, 만일 목표 객체(203)가 큐 객체이면, 2개의 병행 요구, 즉, 큐 객체(203)의 한 구성요소(203n)를 추가하기 위한 제1 요구(205c)와 구성요소(203r)를 제거하기 위한 제2 요구(205d) 모두에게 큐 객체(203)에 대한 병행 억세스가 제공될 수 있으며, 그 이유는 이들 연산이 본래부터 서로 충돌하지 않기 때문이다(이들 연산은 큐의 독립된 구성요소와 관련되어 있음). 그러나, 큐 객체(203)에 구성요소가 존재하지 않으면(큐 객체(203)의 상태가 공백 상태이면), 이들 요구에 병행 억세스가 제공되지 않아야 한다. 그러므로, 제2 요구에 억세스를 허가하기 전에, "양립가능 모드인가"라는 메쏘드(파라미터로서 로크 요구 모드(207d)의 세부사항을 포함함)가 호출될 때, "예:양립가능 모드"라는 응답을 반송하기 전에 공백상태가 아니라는 것을 확인하기 위해 큐 객체(203)의 상태를 검사하게 되는 로직이 로크 요구 모드 객체(207c)에 포함될 수 있다.

로크 요구 모드 객체(207a-207d)는 새로운 요구가 이전의 요구와 충돌하는지 판단하는 데 있어 검사되어야 하는 매우 다양한 요인을 포함하도록 프로그램될 수 있다. 예를 들어, 객체(207a-207d) 내의 소프트웨어는 새로운 요구가 소정의 파라미터를 포함하고 있는지 또한 이들 파라미터의 값이 무엇인지에 관해 검사하기 위한 로직을 포함할 수 있다. 특정 로직의 선택은 임의적이며, 다양한 병행 제어 가능성을 수용하도록 서버 프로그래머에 의해 선택될 수 있다.

본 발명의 양호한 실시예에서 로킹 모드를 표현하기 위해 객체가 사용되기 때문에, 계승(inheritance)과 같은 객체 지향 기술의 전통적인 개념이 활용될 수 있다. 예를 들어, 로킹 모드의 클래스는 특정의 피보호 (목표) 객체(203)에 대해 사용될 기본 로직을 셋업하도록 정의될 수 있다. 그러면, 클래스의 인스턴스는 클래스의 기본 로직과 특정 상황에 특유한 추가적인 로직을 합한 로직을 포함하도록 인스턴스화될 수 있다.

본 발명의 양호한 실시예에서, 표준 OMG CORBA 규격에 더하여 본 발명의 병행 제어 메카니즘을 구현하는 데 필요한 소프트웨어가 제공된다. 즉, 일단 클라이언트 요구가 서버의 ORB로 진행되어 통상적인 ORB 처리(예, ORB의 객체 어댑터 내에 요구를 큐잉하고 디스패치하는 처리 등)를 받으면, 이 요구는 또한, 전술한 바와 같이 병행 제어를 수행하기 위해 추가적인 소프트웨어에 의해 처리된다.

본 발명의 양호한 실시예에서, 이러한 추가의 소프트웨어는, 전통적인 로크 셋트와 동일한 절차명을 갖지만 로크 모드 값 대신에 로크 요구 모드를 수용하는 확장된 모드 로크 셋트를 정의하기 위해 OMG의 OCCS LockSet 인터페이스(전통적으로 단지 수량적으로 계산된 로크 모드 값만을 수용함)를 일반화함으로써 추가된다.

비록 본 발명의 양호한 실시예를 설명하기 위해 객체-지향 기술이 사용되었지만, 본 발명의 다른 실시예에서는 비-객체 지향 구현이 포함될 수 있다. 이들 실시예에서 로크 요구 모드(207a-207d)는 객체로서가 아니라, 예를 들어, 병행 제어 유닛(204)에서 실행되는 메인 프로그램에 의해 호출되는 서브루틴으로서 작성되게된다.

전술한 바와 같은 본 발명에 따르면, 현재 요구의 로크 요구 모드에 대하여 새로운 요구의 로크 요구 모드를 검사하여 충돌 해결을 결정함으로써, 보다 양호한 병행 제어 결과를 얻을 수 있는 효과가 있다.

Claims

클라이언트가 서버 자원에 대한 억세스를 위해 서버에 요구를 전송하는 클라이언트/서버 컴퓨팅 시스템에 사용하기 위한 병행 제어 장치에 있어서,

제1 클라이언트 요구를 수신하고, 상기 제1 요구의 수신에 응답하여 상기 수신된 제1 요구를 기반으로 하는 충돌 해결 로직을 포함하는 제1 로크 요구 모드를 셋업하기 위한 수단과,

제2 클라이언트 요구를 수신하고, 상기 제2 클라이언트 요구의 수신에 응답하여 제2 로크 요구 모드를 셋업하기 위한 수단과,

상기 제1 및 제2 요구에 서버 자원에 대한 병행 억세스가 제공되어야 하는지 판단하기 위해 상기 제1 로크 요구 모드에 포함된 상기 충돌 해결 로직을 이용하여 상기 제1 및 제2 로크 요구 모드를 비교하기 위한 수단

을 포함하는 병행 제어 장치.
제1항에 있어서, 상기 제2 로크 요구 모드는 상기 제2 수신 요구를 기반으로 하는 충돌 해결 로직을 포함하는 것인 병행 제어 장치.
제2항에 있어서, 상기 제2 로크 요구 모드의 상기 충돌 해결 로직은 상기 제1 로크 요구 모드를 기반으로 하는 것인 병행 제어 장치.
제1항에 있어서, 상기 충돌 해결 로직은 클라이언트 요구가 억세스를 요구하고 있는 서버 자원의 상태도 기반으로 하는 것인 병행 제어 장치.
제1항에 있어서, 상기 제1 로크 요구 모드는 객체에 의해 표현되고, 상기 충돌 해결 로직은 상기 객체 내에 캡슐화되는 것인 병행 제어 장치.
제5항에 있어서,

상기 제2 로크 요구 모드는 객체에 의해 표현되는 것이고,

상기 비교 수단은 상기 제1 로크 요구 모드를 표현하는 객체에게로 메시지를 전송하되, 상기 메시지는 상기 제2 로크 요구 모드를 표현하는 객체를 자신의 파라미터로서 전달하는 것인

병행 제어 장치.
클라이언트가 서버 자원에 대한 억세스를 위해 서버에 요구를 전송하는 클라이언트/서버 컴퓨팅 시스템에 사용하기 위한 병행 제어 방법에 있어서,

제1 클라이언트 요구를 수신하고, 상기 제1 요구의 수신에 응답하여 상기 수신된 제1 요구를 기반으로 하는 충돌 해결 로직을 포함하는 제1 로크 요구 모드를 셋업하는 단계와,

제2 클라이언트 요구를 수신하고, 상기 제2 클라이언트 요구의 수신에 응답하여 제2 로크 요구 모드를 셋업하는 단계와,

상기 제1 및 제2 요구에 서버 자원에 대한 병행 억세스가 제공되어야 하는지 판단하기 위해 상기 제1 로크 요구 모드에 포함된 상기 충돌 해결 로직을 이용하여 상기 제1 및 제2 로크 요구 모드를 비교하는 단계

를 포함하는 병행 제어 방법.
제7항에 있어서, 상기 제2 로크 요구 모드는 상기 제2 수신 요구를 기반으로 하는 충돌 해결 로직을 포함하는 것인 병행 제어 방법.
제8항에 있어서, 상기 제2 로크 요구 모드의 상기 충돌 해결 로직은 상기 제1 로크 요구 모드를 기반으로 하는 것인 병행 제어 방법.
제7항에 있어서, 상기 충돌 해결 로직은 클라이언트 요구가 억세스를 요구하고 있는 서버 자원의 상태도 기반으로 하는 것인 병행 제어 방법.
제7항에 있어서, 상기 제1 로크 요구 모드는 객체에 의해 표현되고, 상기 충돌 해결 로직은 상기 객체 내에 캡슐화되는 것인 병행 제어 방법.
제11항에 있어서,

상기 제2 로크 요구 모드는 객체에 의해 표현되는 것이고,

상기 비교 단계를 수행하는 동안에 상기 제1 로크 요구 모드를 표현하는 객체에게로 메시지를 전달하되, 상기 메시지는 상기 제2 로크 요구 모드를 표현하는 객체를 자신의 파라미터로서 전달하는 것인

병행 제어 장치.
컴퓨터 판독가능 매체 상에 저장되어, 클라이언트가 서버 자원에 대한 억세스를 위해 서버에 요구를 전송하는 클라이언트/서버 컴퓨팅 시스템에 사용하기 위한 병행 제어를 수행하기 위한 컴퓨터 프로그램 제품에 있어서,

다음의 기능, 즉,

제1 클라이언트 요구를 수신하고, 상기 제1 요구의 수신에 응답하여 상기 수신된 제1 요구를 기반으로 하는 충돌 해결 로직을 포함하는 제1 로크 요구 모드를 셋업하는 기능과,

제2 클라이언트 요구를 수신하고, 상기 제2 클라이언트 요구의 수신에 응답하여 제2 로크 요구 모드를 셋업하는 기능과,

상기 제1 및 제2 요구에 서버 자원에 대한 병행 억세스가 제공되어야 하는지 판단하기 위해 상기 제1 로크 요구 모드에 포함된 상기 충돌 해결 로직을 이용하여 상기 제1 및 제2 로크 요구 모드를 비교하는 기능

을 수행하기 위한 프로그램 코드 구성요소들

을 포함하는 컴퓨터 프로그램 제품.
제13항에 있어서, 상기 제2 로크 요구 모드는 상기 제2 수신 요구를 기반으로 하는 충돌 해결 로직을 포함하는 것인 컴퓨터 프로그램 제품.
제14항에 있어서, 상기 제2 로크 요구 모드의 상기 충돌 해결 로직은 상기 제1 로크 요구 모드를 기반으로 하는 것인 컴퓨터 프로그램 제품.
제13항에 있어서, 상기 충돌 해결 로직은 클라이언트 요구가 억세스를 요구하고 있는 서버 자원의 상태도 기반으로 하는 것인 컴퓨터 프로그램 제품.
제13항에 있어서, 상기 제1 로크 요구 모드는 객체에 의해 표현되고, 상기 충돌 해결 로직은 상기 객체 내에 캡슐화되는 것인 컴퓨터 프로그램 제품.
제17항에 있어서,

상기 제2 로크 요구 모드는 객체에 의해 표현되는 것이고,

상기 비교 기능을 수행하는 동안에, 상기 제1 로크 요구 모드를 표현하는 객체에게로 메시지를 전송하되, 상기 메시지는 상기 제2 로크 요구 모드를 표현하는 객체를 자신의 파라미터로서 전달하는 것인

컴퓨터 프로그램 제품.