Débiter un compte et créditer un autre sont deux opérations distinctes, mais qui n’ont de sens que réalisées ensemble : si la seconde échoue après que la première a réussi, l’argent disparaît purement et simplement. C’est exactement ce genre de scénario que ce mécanisme permet d’éviter, en garantissant que tout se passe, ou que rien ne se passe.
Une garantie qui dépend du moteur de stockage
Ce mécanisme n’existe que sur les tables utilisant le moteur InnoDB : les anciennes tables MyISAM, encore présentes sur certaines installations WordPress historiques, l’ignorent totalement et valident chaque instruction immédiatement, sans possibilité d’annulation groupée. Trois instructions structurent son usage en SQL : START TRANSACTION ouvre le bloc, COMMIT valide définitivement les changements, et ROLLBACK les annule intégralement en cas de problème détecté en cours de route.
Exemple
<?php
global $wpdb;
$wpdb->query( 'START TRANSACTION' );
$ok = $wpdb->update( $wpdb->options, array( 'option_value' => $nouvelle ), array( 'option_name' => 'ma_cle' ) );
if ( false === $ok ) {
$wpdb->query( 'ROLLBACK' );
} else {
$wpdb->query( 'COMMIT' );
}
Bon à savoir
- WordPress lui-même n’utilise pratiquement jamais ce mécanisme dans son cœur : c’est un outil que le développeur mobilise volontairement pour ses propres opérations sensibles, via
$wpdb->query(). - Une transaction laissée ouverte trop longtemps peut verrouiller des lignes et bloquer d’autres requêtes concurrentes : elle doit rester la plus courte possible.
- Ne confondez pas ce mécanisme avec une simple sauvegarde préventive : une transaction protège la cohérence pendant l’exécution, pas contre une erreur découverte des jours plus tard.