12.4. V�rification de coh�rence des donn�es au niveau de l'application

Comme les lecteurs ne verrouillent pas les donn�es avec PostgreSQL, quelque soit le niveau d'isolation, les donn�es lues par une transaction peuvent �tre surcharg�es par une autre transaction concurrente. En d'autres termes, si une ligne est renvoy�e par SELECT, cela ne signifie pas que la ligne est toujours courante au moment o� elle est renvoy�e (c'est-�-dire, quelque temps apr�s que la requ�te courante n'ait commenc�). La ligne pourrait avoir �t� modifi�e ou supprim�e par une transaction valid�e apr�s le lancement de cette requ�te. M�me si la ligne est toujours valide <<�maintenant�>>, elle pourrait �tre modifi�e ou supprim�e avant que la transaction courante ne soit valid�e ou annul�e.

Une autre fa�on de penser � ceci est que chaque transaction voit une image du contenu de la base de donn�es et les transactions concurrentes en cours d'ex�cution pourraient tr�s bien voir des images diff�rentes. Donc, le concept entier de <<�maintenant�>> est quelque peu mal d�fini. Ceci n'est habituellement pas un gros probl�me si les applications clientes sont isol�es les unes des autres, mais si les clients peuvent communiquer via des canaux externes � la base de donn�es, de s�rieuses confusions pourraient survenir.

Pour s'assurer de la validit� actuelle d'une ligne et pour la prot�ger contre les modifications concurrentes, vous devez utiliser SELECT FOR UPDATE ou une instruction LOCK TABLE appropri�e. (SELECT FOR UPDATE verrouille uniquement les lignes retourn�es contre les mises � jours concurrentes alors que LOCK TABLE verrouille la table enti�re.) Ceci doit �tre pris en compte lors du portage d'applications vers PostgreSQL depuis d'autres environnements. (Avant la version 6.5, PostgreSQL utilisait des verrous de lecture et, du coup, cette consid�ration est aussi valable pour les versions ant�rieures � la version 6.5 de PostgreSQL.)

Des v�rifications globales de validit� requi�rent une r�flexion suppl�mentaire avec MVCC. Par exemple, une application bancaire pourrait souhaiter v�rifier que le somme de tous les cr�dits d'une table est �quivalent � la somme des d�bits d'une autre table lorsque les deux tables sont activement mises � jour. Comparer les r�sultats de deux commandes SELECT sum(...) successives ne fonctionnera pas correctement avec le mode de lecture valid�e car la deuxi�me requ�te a des chances d'inclure les r�sultats de transactions non comptabilis�es dans la premi�re. Faire les deux sommes dans une seule transaction s�rialis�e donnera une image plus pr�cise des effets des transactions valid�es avant le d�but de la transaction s�rialisable — mais vous pourriez vous demander si la r�ponse est toujours juste au moment o� elle est fournie. Si la transaction s�rialisable a elle-m�me appliqu� des modifications avant de tenter la v�rification de coh�rence, l'utilit� de la v�rification devient bien plus discutable car, maintenant, elle inclut des modifications apparues apr�s le d�but de la transaction mais pas toutes. Dans de tels cas, une personne attentionn�e pourrait souhaiter verrouiller toutes les tables n�cessaires � la v�rification pour obtenir une image indiscutable de la r�alit�. Un verrou de mode SHARE (ou plus important) garantit qu'il n'y a aucune modification non valid�e dans la table verrouill�e, autres que celles de la transaction.

Il est � noter que si vous voulez vous reposer sur les verrous explicites pour �viter les changements concurrents, vous devriez utiliser le mode Read Commited, ou alors, dans le mode s�rialisable, �tre attentif � l'obtention des verrous avant d'effectuer des requ�tes. Un verrou obtenu par une transaction s�rialisable garantit qu'aucune autre transaction modifiant la table n'est en cours d'ex�cution mais si l'image vue par la transaction est ant�rieure � l'obtention du verrou, elle pourrait �tre ant�rieure aux quelques modifications maintenant valid�es dans la table. Une image de la transaction s�rialisable est g�n�ralement gel�e au d�but de la premi�re requ�te ou de la premi�re commande de modification de donn�es (SELECT, INSERT, UPDATE ou DELETE). Du coup, il est possible d'obtenir des verrous de fa�on explicite avant que l'image ne soit gel�e.