root/traduc/trunk/slony/raceconditions.xml

<?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;
 <ulink url="http://www.wikipedia.org/"> Wikipedia </ulink>
décrit ce terme ainsi : <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 des applications distribuées ou multiprocesseurs lorsque différentes partie 
de l'application dépendent de certains éléments partagé; si ce partage
est mal géré, des confusions (erreurs !) apparaissent. Plus précisément,
cela impliquent en général les situations où l'état de partage peut 
être changé entre le moment ou il est vérifié et le moment ou il est utilisé.
</para>

<para> &slony1; a connu un certain nombre de situations de compétition au cours de son histoire :

<itemizedlist>

<listitem><para> Entre la version 1.0 et la version 1.1,
   <xref linkend="stmtmoveset"/> a avait un problÚme car les noeuds n'avait 
     aucun moyen d'empêcher le traitement des événements <command>SYNC</command>
     en provenance du noeud 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 noeud origine; Ceci permettait
aux abonnés d'être conscients qu'il devait attendre l'événement 
<command> MOVE SET </command>.</para> </listitem>

<listitem><para>Dans un certain nombre d'endroits, &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 timestamps 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 bug, le <link linkend="logshipping"> log shipping </link>
    avait une situation de compétition où chaque fois que la configuration
    était rechargée par le &lslon; ( comme cela arrive souvent, notamment avec
    linkend="stmtsubscribeset"/>), il y avait un risque que les identifiant de 
  <command>SYNC</command> utilisé 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 un variable située en mémoire (donc génératrice de problÚmes ) en un 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 joliment 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>