`@ transaction.non_atomic_requests '에 적합한 요청 유형은 무엇입니까?

Question

transactions을 웹에서 처리하는 일반적인 방법은 각 요청을 트랜잭션으로 래핑하는 것입니다. Django에서는이 동작을 활성화하려는 각 데이터베이스의 구성에서 ATOMIC_REQUESTS을 True로 설정할 수 있습니다.

다음과 같이 작동합니다. Django는 뷰 함수를 호출하기 전에 트랜잭션을 시작합니다. 문제없이 응답이 생성되면 Django는 트랜잭션을 커밋합니다. 뷰가 예외를 생성하면 Django는 트랜잭션을 롤백합니다.

이 트랜잭션 모델의 단순성은 매력적이지만 트래픽이 증가 할 경우 비효율적입니다. 모든보기에 대한 트랜잭션 열기에는 약간의 오버 헤드가 있습니다.

transactions으로 묶을 필요가없는 요청의 경우 @transaction.non_atomic_requests 데코레이터를 적용 할 수 있습니다.

Django view.py에는 여러 가지보기 클래스와 요청 방법이 있습니다. 어떤 요청이 비 원자 장식자를위한 좋은 후보자가 될지 결정하는 방법에 대해 어떻게 생각하나요?

"잡았다"는 숨어있을 수 있습니다.

나는 과 함께 좋은 후보자 또는 아무것도하지 않는 방법을 볼 수 있었지만 그 외 무엇을주의해야합니까?

Answer 1

불행히도 일반적으로 적용 할 수있는 힌트, 잡아 당김 등이 많지 않다고 생각합니다. 질문은 단지 다음과 같습니다.이 작업 순서는 수행 할 수있는 모든 데이터베이스 작업을 고려할 때 데이터베이스 트랜잭션이 올바르게 작동해야합니까? 대답이 '예'(또는 확실하지 않은 경우) 인 경우 거래를 사용하십시오. 그렇지 않다면하지 마십시오.

매우 구체적인 애플리케이션 관련 질문입니다. 예를 들어, save()에는 트랜잭션이 필요하고 그렇지 않은 경우가 많은 경우가 많이 있습니다. 나는 앉아서 그 가능성을 생각하는 대신에 어떤 것을 모르고있다.

가장 중요한 것은 데이터베이스 트랜잭션을 잘 이해하는 것입니다. 특히 isolation levels입니다. 실제로 사람들은 트랜잭션의 정신 모델이 SERIALIZED 분리 레벨과 일치하므로 실제로는 조작이 READ COMMITTED (Django 기본값)을 사용하고있어 일부 동시성 문제로 인해 안전하다고 잘못 생각합니다.

잠금 (예 : Django의 select_for_update()) 및 낙관적 인 동시성과 같은 일반 거래 외에 사용할 수있는 다른 도구를 이해하고 고려하는 것도 중요합니다.