Terracotta의 영구 데이터의 경우 클래스를 발전시키는 방법은 무엇입니까?

Question

우리는 고려 중입니다 테라코타 다음 프로젝트를 위해.별도의 DBMS 없이도 데이터 지속성을 제공할 수 있는 잠재력에 흥미를 느낍니다.(또한보십시오 지속성 솔루션으로 Terracotta 사용에 대해)

소프트웨어 진화의 주요 어려움 중 하나는 기존 생산 데이터를 새로운 데이터 모델에 맞게 만드는 것입니다.RDBMS의 경우 배포 시점에 SQL 변경 스크립트를 사용할 가능성이 높습니다.Terracotta 기반 데이터의 경우 사소하지 않은 진화를 처리하는 방법이 즉시 명확하지 않습니다.

거기에 Terracotta 문서의 클래스 진화에 관한 몇 개의 단락 그러나 이는 DSO에만 국한된 것으로 보이며 다소 피상적입니다.

1. Terracotta에 저장된 영구 데이터에 대한 데이터 모델 진화를 처리할 수 있는 방법은 무엇입니까? 나는 특히 DSO가 아닌 시나리오에 관심이 있습니다(예:Terracotta Toolkit API를 통해).
2. Terracotta DSO와 Toolkit API는 진화된 클래스 정의에 대한 반응이 다릅니까?
3. 클래스 진화의 한계를 이해하려면 Terracotta가 객체 데이터를 어떻게 표현/전달하는지 아는 것이 도움이 될 것입니다.그것에 대한 사양이 있습니까?
4. 어쩌면 Terracotta에 적용할 수 있는 OODBMS 세계의 스키마 진화 기술이 있을까요?

간단한 예로, 내가 여러 개의 Car 저장된 객체와 내가 변경한 객체 modelYear 분야 Car 수업은 String 에 int.문서에 따르면 이는 기본적으로 작동하지 않습니다.나는 내 오래된 솔루션을 상상할 수 있습니다. Car 애플리케이션 시작 중에 별도의 클래스 로더에 의해 로드된 후 새로운 클래스로 변환됩니다. Car.그것이 좋은 접근 방식일까요? 그 이유는 무엇입니까?

Answer 1

사용 사례 시나리오에 따라 다릅니다.

캐시를 로드하는 데 드는 비용이 최소(분)이고 가동 중지 시간이 허용된다면 새 버전을 위해 캐시를 다시 구축하는 것만으로는 문제가 되지 않습니다.

캐시를 채우는 데 드는 비용(시간/일)이 높고 상당한 가동 중지 시간을 감당할 수 없는 경우 전환 기간 동안 새 버전과 이전 버전을 동시에 처리해야 합니다.이를 위해:

1. 캐시 된 클래스의 새 버전에 대한 별도의 캐시 정의를 정의하고 이전 버전이 캐시에서 만료되도록합니다.
2. 애플리케이션 코드에는 "이전/새 버전"도 지원되어야 합니다.
3. 데이터가 만료 될 때까지 오래된 버전과 함께 작동하는 인스턴스가있어 (이전 캐시 이름을 기준으로)
4. 새 버전으로 모든 새 요청/흐름을 처리 한 인스턴스가 있습니다 (새 캐시 이름을 기준으로)

예를 들어ehcache.xml에서 2개의 캐시를 정의합니다(귀하의 예에 따라):

<cache name="com.xyz.Car" timeToLiveSeconds="600"/>
<!--New version goes here-->
<cache name="com.xyz.Car2" timeToLiveSeconds="600"/>

장기적으로는 버전 발전을 포함하는 캐시 명명 규칙을 연습해야 합니다.