2013-06-03 2 views
4

lors de l'utilisation stratégie de verrouillage optimiste, il peut résoudre le problème de la concurrence comme ci-dessous:Optimistic-Locking est-il absolument sûr?

 
| the first transaction started  | 
|          | 
| select a row       | 
|          | the second transaction started 
| update the row with version checking | 
|          | select the same row 
| commit txn       | 
|          | update the row with version checking 
|          | 
|          | rolls back because version is dirty 

Mais si dans les cas extrêmement rares si la mise à jour dans la deuxième transaction est postérieure à la udpate dans la première transaction, mais avant la la transaction s'engage?

 
| the first transaction started  | 
|          | the second transaction started 
| select a row       | 
|          | select the same row 
| update the row with version checking | 
|          | update the row with version checking 
| commit txn       | 
|          | rolls back because version is dirty // will it? 
|          | 
|          | 

J'ai fait une expérience que la mise à jour dans la deuxième transaction ne pouvait pas lire la version « sale » parce que la première transaction n'a pas été commis encore. La deuxième transaction échouera-t-elle dans ce cas?

+0

@Adam Arold Merci de m'avoir dit cet aphorisme. Je google parce que je ne suis pas un anglophone natif :) Mais la stratégie optimiste-verrouillage fonctionnera-t-elle dans le cas que j'ai mentionné? – Hippoom

+0

Si c'est vraiment optimiste, comment se fait-il que vous utilisiez la fonction de transaction? La mise à jour échouera d'elle-même sans avoir besoin de revenir en arrière. – tia

+0

@tia Peut-être dans l'exemple, c'est ok avec ou sans transactions.Mais parfois j'ai besoin d'annuler d'autres changements (par exemple peut-être des insertions à une sous-table) à la base de données – Hippoom

Répondre

2

Vous n'avez pas précisé dans votre question quel système de base de données vous utilisez réellement, donc je ne connais pas les détails de votre système.

Mais dans tous les cas, sous un système de verrouillage optimiste, un processus ne peut pas simplement vérifier les versions des lignes lorsqu'il exécute l'instruction de mise à jour, à cause précisément du problème qui vous inquiète. Pour les transactions entièrement sérialisables et isolées, chaque processus doit vérifier de manière atomique les versions de ligne de toutes les lignes qu'il a examinées et modifiées, au moment de la validation. Ainsi, dans votre deuxième scénario, le processus de droite ne détectera pas un conflit tant qu'il ne tentera pas de valider (une étape que vous n'avez pas incluse dans le processus de droite). Quand il essaye de commettre, il détectera le conflit et reculera.

+0

Merci pour la réponse. Nous utilisons Oracle 10g dans l'environnement de production, le niveau d'isolement est lu engagé. – Hippoom

+0

Va-t-il vraiment échouer quand il essaye de commettre. Je veux dire qu'il ne lèvera pas d'exception quand la vérification de nombre échoue en utilisant optimistic-locking, il mettra juste 0 lignes à la place et le développeur jette une exception quand la ligne affectée est égale à 0. – Hippoom

+0

Peut-être que je peux faire une autre expérience update sql est exécuté mais avant de valider la transaction et de mettre à jour la même ligne dans un autre thread puis de réveiller le premier thread. – Hippoom

Questions connexes