Comment prévenir le problème de concurrence dans la mise à JOUR via iBatis

Votre problème n'est pas avec des transactions, c'est qu'avant de modifier quelque chose que vous devez être sûr que personne n'a modifié depuis votre dernière lecture.

Dans les applications web, vous devez utiliser le verrouillage optimiste. Fondamentalement, vous avez une "version" du champ dans votre table, qui a une valeur initiale à insert (typiquement 1), et est incrémenté à chaque update. La procédure est la suivante:

1. Lire les données de la table, y compris le champ version

2. Envoyer des données côté client, y compris le champ version

3. Recevoir des données modifiées par le client, y compris le champ version inchangé

4. Mise à jour de la table et incrémentation de la version, mais seulement si le champ version en ligne est le même que celui d'origine a reçu de la part du client. C'est là où vous aviez

   update
   ... 
   where id = :id_from_client

   vous pouvez maintenant faire

   update 
   ..., 
   version = version + 1 
   where 
   id = :id_from_client and 
   version = :version_from_client

5. Obtenir le nombre de lignes mises à jour (vous pouvez généralement obtenir ces informations à droite à partir de l'opération de mise à jour de votre infrastructure de persistance). Si le nombre de lignes mises à jour est de 1, l'opération a réussi. Si le nombre de lignes mises à jour est 0, vous devez signal d'une simultanéité d'erreur.

Un exemple:

1. User1 obtenir les données, avec la version = 17

2. User2 obtenir les données, avec la version = 17

3. User1 automatiquement (atomicité d'une seule instruction SQL):

   • Vérifier si la version = 17
   • Met à jour les données
   • Jeux version à 18

4. User2 atomiquement:

   • Vérifier si la version = 17
   • Que la version était vraiment 18, les signaux d'une simultanéité d'erreur et interrompt l'opération, informant l'utilisateur que l'opération n'a pas pu être terminé en raison de quelqu'un d'autre de modifier les mêmes données.

Le plus courant de la persistance des cadres de soutien pour cette sortie de la boîte et la plupart du temps automatiquement (voir JPA @Version annotation, par exemple). iBatis ne semble pas l'avoir, mais comme il est très proche de SQL, vous ne devriez pas avoir beaucoup de problèmes de mise en œuvre vous-même. Voir cette entrée de blog pour quelques détails sur le verrouillage optimiste avec iBatis.

Avec ce régime, vous ne serez pas perdu mises à jour, le seul problème est que certains cas spécifiques ennuyer les utilisateurs beaucoup: imaginez-vous passer 5 minutes pour remplir une certaine forme seulement d'être dit à la fin de votre opération n'a pas pu être terminé et que vous avez besoin pour recommencer depuis le début!! Dans ces quelques cas, vous devez mettre en œuvre quelque chose de plus sophistiqué sur le dessus de verrouillage optimiste. Je voudrais utiliser une sorte de ressource éloignée de location (liens??):

1. Le client demande un location pour les données au serveur.

2. Si les données sont déjà loués à un autre client, le signal d'une simultanéité d'erreur.

3. D'autre octroyer le contrat de location, le client pour une quantité limitée de temps.

4. Avant l'expiration du bail, le serveur accorde au client un accès exclusif aux données. Le client peut aussi demander un renouvellement de bail (via AJAX, par exemple). Le serveur peut accepter ou refuser le renouvellement. (Les durées de bail et le renouvellement des politiques devrait être décidé par le serveur en fonction du cas d'utilisation qui est en cours de traitement).

5. L'expiration du bail (ce qui peut être fait avec une tâche planifiée sur le serveur, par exemple). Lorsque le bail expire, les données doivent être considérées comme "déverrouillé", et le serveur doit refuser l'accès pour le client, sauf si le client est accordé un nouveau contrat de location.

De cette façon, vos utilisateurs peuvent être informés que quelqu'un est en train de modifier les mêmes données avant qu'ils commencent même à quelle opération longue, ils ont été en essayant de terminer.

OriginalL'auteur gpeche