Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

118 lines (99 sloc) 4.802 kb
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="raceconditions">
<title>Situations de compétition et &slony1;</title>
<indexterm><primary>situations de compétition</primary></indexterm>
<para>
Non, il ne s'agit pas compétitions sportives&nbsp;; <ulink
url="http://www.wikipedia.org/">Wikipedia</ulink> décrit ce terme ainsi&nbsp;:
<quote>Une situation de compétition, plus couramment nommée race condition,
est un défaut dans un système électronique ou informatique, non prévu lors
de la conception, caractérisé par un résultat différent selon l'ordre dans
lequel sont effectuées certaines opérations du système. Lorsqu'une situation
de compétition se produit, cela peut avoir des effets néfastes pendant une
longue période, et le système peut nécessiter d'être réinitialisé.</quote>
Dans les applications informatiques, les situations de compétitions arrivent
la plupart du temps au sein d'applications distribuées ou multiprocesseurs
lorsque différentes parties de l'application dépendent de certains éléments
partagé&nbsp;; si ce partage est mal géré, des confusions (erreurs&nbsp;!)
apparaissent. Plus précisément, cela implique en général des situations où
l'état de partage peut être changé entre le moment où il est vérifié et le
moment où il est utilisé.
</para>
<para>
&slony1; a connu un certain nombre de situations de compétition au cours de
son histoire&nbsp;:
<itemizedlist>
<listitem>
<para>
Entre la version 1.0 et la version 1.1, <xref linkend="stmtmoveset"/>
avait un problème car les n&oelig;uds n'avaient aucun moyen d'empêcher
le traitement des événements <command>SYNC</command> en provenance du
n&oelig;ud origine (qu'ils considéraient comme un simple fournisseur,
et pas comme une source de données à répliquer) avant de reconnaître
le changement de rôle (d'abonné à fournisseur).
</para>
<para>
Ceci fût corrigé en introduisant un nouvel événement <command>ACCEPT
SET</command> qui était soumis par le nouveau n&oelig;ud origine; Ceci
permettait aux abonnés d'être conscients qu'ils devaient attendre
l'événement <command>MOVE SET</command>.
</para>
</listitem>
<listitem>
<para>
Dans un certain nombre d'emplacements, &slony1; utilise la commande
SQL <command>lock table sl_config_lock;</command> afin d'éviter les
situations de compétitions lorsque la valeur de la séquence
sl_log_status est changée.
</para>
</listitem>
<listitem>
<para>
L'option &lslon; <xref linkend="slon-config-sync-interval-timeout"/>
est utilisée pour éviter les situations de compétition dans lesquelles
la séquence d'action est dégagée par le trigger au moment de l'insertion
de ligne de log, ce qui rend le <quote>dégagement</quote> immédiatement
visible au processus de synchronisation, alors que la ligne de log
correspondante n'est pas encore visible.
</para>
</listitem>
<listitem>
<para>
L'approche dite de <quote>visibilité des images</quote> utilisée par
&slony1; pour déterminer quelle donnée répliquée doivent être associée
avec un <command>SYNC</command> spécifique, évite les situations de
compétition qui se produisent lorsque l'on essaie d'utiliser simplement
des horodatages ou des plages d'identifiants pour déterminer quelles
données doivent être répliquées.
</para>
</listitem>
<listitem>
<para>
Dans la branche 1.2, jusqu'à la version 1.2.11 qui corrige ce bogue,
le <link linkend="logshipping">log shipping</link> avait une situation
de compétition à chaque fois que la configuration était rechargée par
le &lslon; (comme cela arrive souvent, notamment avec <link
linkend="stmtsubscribeset"/>), il y avait un risque que les identifiants
de <command>SYNC</command> utilisés pour l'ordonnancement correct et
pour l'exécution du log shipping soient décalées d'une unité.
</para>
<para>
Ceci fut corrigé dans la version 1.2.11 en transformant le numéro
d'identifant, qui était une variable située en mémoire (donc
génératrice de problèmes) en une donnée transactionnelle, stockée dans
la base de donnée de l'abonné.
</para>
<para>
Ce problème ne fut jamais découvert lors des <link
linkend="testbed">bancs d'essai</link> démontrant simplement que les
situations de compétitions sont souvent très dépendantes du type de
données stockée ou du rythme de l'application.
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
Jump to Line
Something went wrong with that request. Please try again.