우리는 애플리케이션 엔진에 복잡한 개체를 삭제하는 트랜잭션을 시작하는 경우와 객체, 우리는 문제가에 삭제해야 첨부 된 일부 BLOB 참조를 가지고있다. blob을 삭제하면 트랜잭션이 실패 할 수 있지만 blob은 사라집니다. blobstore가 독립적으로 작동하기 때문에 (트랜잭션 개념에 위배됩니다).BLOBstore 삭제 작업을 ndb로 안전하게 처리하려면 어떻게해야합니까?
이제 우리는이 멋진, 새로운 NDB 느릅 나무는 문제를 해결할 수있는 문서화 된 API (?)없이 상황에 맞는 캐시를 가지고있다.
toolchest을 :
- ndb.get_context()
def delete_blobs_call_on_commit(): ndb_context = ndb.get_context() blobstore.delete(ndb_context.list_of_blobkeys_to_delete) # OR: taskqueue.add(url+ndb_context.list_of_blobkeys_to_delete)
작업
ndb_context.call_on_commit (delete_blobs_call_on_commit) (NDB의 함수 참조 문서화)에 연결을 blobkeys 컨텍스트 개체에 대한 트랜잭션 중에 삭제하고 트랜잭션 후에 삭제하십시오.
는 업데이트 : call_on_commit() 데이터베이스 작업 (즉 blobstore.delete을 포함 할 수 있지만 시도하지 않은)을 허용하지 않습니다와 BadRequestError가 발생합니다 : 완성 된 트랜잭션에 새로운 작업을 시작할 수 없습니다, 그래서이 유일한 해결책 수도 정말로 작업 대기열이됩니다.
업데이트 : call_on_commit()에 등록 된 함수에서 @ ndb.non_transactional 데코레이터로 함수를 호출 할 수 있습니다. 따라서 커밋 성공시 BLOB를 삭제하고 예외가 없으면 고아가되지 않기를 바랍니다.
질문 : 어떻게 안전하게 상황에 맞는 캐시를 사용하는? 얼룩 삭제 문제는 어떻게 해결 했습니까? 당신이 거래에서 사용할 수있는 단지 있도록
어떻게이 문제를 해결할 것인가? blobkey의 삭제가 여전히 실패 할 수 있으며 이제는 고아 BLOB가 있습니다.두 가지 삭제를 모두 추적하고 작업에서 실행하는 롤 포워드 트랜잭션 모델을 사용해보십시오. 작업은 모든 것이 삭제되었음을 확인한 다음 자체를 정리합니다. 어느 시점에서 실패하면 스위퍼는 앞으로 나가고 모든 엔티티가 사라질 때까지 재 시도 할 수 있습니다. 그냥 제안. –
모든 BLOB 삭제를 작업 대기열로 푸시하고 트랜잭션이 실패 할 경우 작업을 삭제하는 것을 고려했지만 이는 불편합니다. delete_blobs_call_on_commit()은 blob을 직접 지우지 않고 여전히 작업 대기열을 사용할 수 있지만, 고아가 몇 개인 경우 허용 가능하다고 생각했습니다. blobstore의 성공률이 99.9 %이면 괜찮을 수 있습니다. 주로이 질문은 롤 포워드 데이터를 수집하는 것을 다룹니다. – cat
이 기사를 읽었습니까? http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engine –