Quels types de demandes font un bon candidat pour `@ transaction.non_atomic_requests`?

Question

Une façon courante de gérer transactions sur le Web consiste à emballer chaque demande dans une transaction. Dans Django, vous pouvez définir ATOMIC_REQUESTS sur True dans la configuration de chaque base de données pour laquelle vous souhaitez activer ce comportement.

Cela fonctionne comme ceci. Avant d'appeler une fonction de vue, Django lance une transaction. Si la réponse est produite sans problème, Django valide la transaction. Si la vue génère une exception, Django annule la transaction.

Bien que la simplicité de ce modèle de transaction soit attrayante, elle la rend également inefficace lorsque le trafic augmente. L'ouverture d'une transaction pour chaque vue a une certaine surcharge.

Pour les demandes qui n'ont pas besoin d'être enveloppées dans transactions, vous pouvez appliquer le décorateur @transaction.non_atomic_requests.

Étant donné un Django view.py avec plusieurs classes View et méthodes de requête. Comment pourrais-je décider quelles demandes feraient de bons candidats pour le décorateur non-atomique?

Qu'est-ce que "gotchas" pourrait être caché?

Je pouvais voir POST méthodes ne faisant pas de bons candidats ou quoi que ce soit avec un .save(), mais quoi d'autre devrais-je faire attention?

Answer 1

Malheureusement, je ne pense pas qu'il y ait beaucoup de trucs, astuces, et ainsi de suite qui sont généralement applicables. La question est juste: cette séquence d'opérations nécessite-t-elle une transaction de base de données pour fonctionner correctement, étant donné toutes les opérations de base de données que je pourrais effectuer? Si la réponse est oui (ou vous n'êtes pas sûr), utilisez une transaction; sinon, ne le fais pas.

C'est une question très spécifique à l'application. Prenant votre exemple, il y a beaucoup de situations où un save() exigera une transaction et beaucoup où ce ne sera pas. Je ne connais aucun substitut à simplement s'asseoir et penser à travers les possibilités.

La chose la plus importante est de bien comprendre les transactions de base de données, en particulier isolation levels. Les gens pensent souvent à tort qu'ils sont à l'abri de certains problèmes de simultanéité parce que leur modèle mental de transactions correspond au niveau d'isolement SERIALIZED, alors qu'en fait leurs opérations utilisent READ COMMITTED (la valeur par défaut de Django).

Il est également important de comprendre et de prendre en compte les autres outils disponibles que vous pouvez utiliser en plus des transactions simples, comme les verrous (par exemple select_for_update() de Django) et la concurrence optimiste.