2012-08-16 2 views
2

ZODB에 병렬 쓰기 요청을 실행합니다. ZODB 내에 복수 BTree 개의 인스턴스가 있습니다. 서버가 BTree 내부의 동일한 객체에 액세스하면 IOBucket 클래스에 대해 ConflictError이 표시됩니다. 모든 장고베이스 클래스에 대해 _p_resolveconflict을 설정했지만 IOBucket을 구현할 수는 없으므로 C 기반 클래스가 필요합니다.ZODB의 충돌 해결

나는 더 깊은 분석을했지만, 여전히 IOBucket 클래스에 대해 불평하는 이유와 그것에 쓰는 이유를 이해하지 못합니다. 또한이를 해결할 올바른 전략은 무엇입니까?

도움을 주셔서 감사합니다.

답변

1

IOBucketBTree의 지속성 구조의 일부입니다. 충돌 오류를 줄이기 위해 존재하며 가능한 경우 충돌을 시도하고 해결합니다.

그런데 충돌이 항상 피할 수있는 것은 아니므로 거래를 다시 시작해야합니다. 예를 들어, Zope에서 ConflictError이 발생하면 전체 요청이 최대 5 회 재실행됩니다. 충돌은 ZODB의 두 가지 요청이 똑같은 데이터 구조를 변경하려고 시도한 (희망 적으로 드문 경우) 상황을 처리하는 방법입니다.

거래를 다시 시작한다는 것은 transaction.begin()을 호출하고 동일한 변경 사항을 다시 적용한다는 것을 의미합니다. .begin()은 다른 프로세스가 변경 한 내용을 가져오고 커밋은 새로운 데이터를 기반으로합니다.

+0

친애하는 저는 django_zodb를 사용합니다. 여기서는 트랜잭션이 아주 일찍 시작되어서 가로 채지 않을 것입니다. 내가 어제 발견 한 것은 변경 전의 root._p_jar.sync() 호출과 데이터 저장소 변경 후 transaction.savepoint가 충돌 오류를 해결한다는 것입니다. 나는 논리를 완전히 이해하지 못했지만. 그것은 의미가 있습니까? 아니면 이상한 것이 었나요? – patroqueeet

+0

다른 질문 : 약 5 시간 동안 예외를 잡아 내고 몇 밀리미터를 기다린 후 완전히 새로운 거래로 다시 시도하는 지붕을 만드는 것이 합리적일까요? 그렇다면 내 생각에, 내 트랜잭션은 서버 요청에서 시작하고 응답이 렌더링 될 때 끝납니다. 이게 쓸모 없을거야? 따라서 제 안전한 환경에서는 복잡한 트랜잭션이 zodb에 대한 좋은 접근 방법이되지 않습니까? 이러한 거래는 더 많은 ACID와 같아야합니까? – patroqueeet

+0

@patroqueeet :'_p_jar.sync()'는 최신 데이터를로드하는 것을 의미합니다 (즉, 일관성없는 상태로 작업 할 수 있음을 의미합니다). '세이브 포인트 (savepoint) '는 커밋 시간까지 디스크에 변경 사항을 플러시하여 (메모리를 비우는) 방법 일뿐입니다. –