Reprise après échecs sur transaction dus à un verrouillage optimiste

Il existe trois stratégies principales qui permettent d'effectuer une reprise après un échec de transaction si des conflits se sont produits dans la base de données en raison d'un verrouillage optimiste : Sérialisation, Relance, Ignorer. Le choix de ces stratégies dépend de l'importance ou de la gravité relative de la transaction en question.

Procédure

Sérialisation
La première stratégie consiste à sérialiser la transaction ayant échoué. La sérialisation applique ordonnancement des opérations sur la base de données afin d'assurer qu'aucune autre transaction ne met à jour le même jeu de résultats pendant sa lecture et son écriture par une transaction. En d'autres termes, la sérialisation sur un ensemble d'opérations de base de données permet l'annulation temporaire de la libération qu'offre un verrouillage optimiste.
Par exemple, si de nombreux utilisateurs effectuent fréquemment une transaction donnée, la probabilité de conflit pendant le même jeu d'opérations est élevée. La sérialisation peut la réduire en canalisant les utilisateurs dans cette section d'opérations, un à la fois, par l'application temporaire d'une stratégie plus pessimiste sur cette section critique de code.
La sérialisation est avantageuse lorsque :
- La transaction est de nature critique et que vous ne souhaitez pas d'échec sur les transactions critiques.
- La mise à jour de la base de données peut provoquer un grand nombre de conflits.
Remarque : Par défaut, la table INVENTORY est sérialisée à l'aide de select for update.
La sérialisation peut augmenter potentiellement le rendement de cette opération lorsque le taux d'erreurs est élevé sans sérialisation (c'est-à-dire que des conflits se produisent fréquemment) en empêchant les utilisateurs de relancer l'opération.
L'occurrence de l'une des exceptions suivantes dans le journal de HCL Commerce indique qu'un échec de mise à jour optimiste s'est probablement produit :

com.ibm.ejs.persistence.OptimisticUpdateFailureException: executeUpdate returned zero rows updated

Cette exception se produit lorsque l'échec a lieu quand le conteneur EJB tente de mettre à jour le bean entity.

com.ibm.commerce.base.helpers.ECJDBCOptimisticUpdateFailureException

Cette exception se produit lorsque l'échec a lieu quand un bean session tente de mettre à jour une ligne d'une table de base de données.

Pour forcer les instructions SELECT et UPDATE à avoir lieu l'une après l'autre (sérialiser), remplacez le niveau d'isolement de l'opération en cours par ReadStability.
- Remplacez l'instruction SELECT problématique par SELECT . . . FOR UPDATE WITH RS.
- Remplacez l'instruction SELECT par SELECT . . .FOR UPDATE.
Remarque : Pour la sérialisation des beans EJB, ne modifiez pas les beans existants. Utilisez des requêtes JDBC qui utilisent SELECT ... FOR UPDATE, comme indiqué ci-dessus.
Nouvel essai
La seconde stratégie consiste à relancer l'instruction ayant échoué. Il existe un mécanisme dans le moteur Transaction server qui vous permet de réexécuter une commande en cas d'échec.
Voir Permettre les nouvelles tentatives des commandes du contrôleur.
La valeur par défaut de la propriété retriable est true. Une implémentation de commande peut remplacer cette valeur, bien que la façon normale de la remplacer sans modifier de code est de la spécifier explicitement dans la valeur de la colonne PROPERTIES de la table de base de données CMDREG. Par exemple, si la valeur de la colonne CMDREG.PROPERTIES spécifie retriable=false, la commande n'est pas retentée lorsque sa transaction de base de données est annulée.
Relancer une instruction ayant échoué comporte des avantages si la probabilité de conflit est faible. La relance d'une instruction est plus coûteuse que la sérialisation, mais pour des conflits d'opérations peu fréquents, elle est préférable.
Ignorer
Si les transactions qui échouent sont insignifiantes (les utilisateurs finaux peuvent actualiser leurs navigateurs et poursuivre), vous pouvez ignorer l'erreur.