Changeset 965

Show
Ignore:
Timestamp:
03/28/08 00:44:57 (8 months ago)
Author:
daamien
Message:

1ere trad, à relire !

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/raceconditions.xml

    r937 r965  
    44     par      $Author$ 
    55     révision $Revision$ --> 
    6 <sect1 id="raceconditions"><title>Race Conditions and &slony1;</title> 
     6<sect1 id="raceconditions"><title>Situations de compétition et &slony1;</title> 
    77 
    8 <indexterm><primary>race conditions</primary></indexterm> 
     8<indexterm><primary>situations de compétition</primary></indexterm> 
    99 
    10 <para> No, this has nothing to do with racial harmony or lack thereof; 
    11 the <ulink url="http://www.wikipedia.org/"> Wikipedia </ulink> 
    12 describes it thus: <quote>A race condition or race hazard is a flaw in 
    13 a system or process whereby the output of the process is unexpectedly 
    14 and critically dependent on the sequence or timing of other 
    15 events. </quote> In computing applications, race conditions arise most 
    16 frequently in distributed or threaded applications when multiple parts 
    17 of the application depend on some piece of shared state, and, if this 
    18 state is not properly managed, confusion (error!) arises. More 
    19 particularly, this usually involves situations where the state can 
    20 change between the time it was checked and the time of use of the 
    21 state. </para> 
     10<para> Non, il ne s'agit pas compétitions sportives; 
     11 <ulink url="http://www.wikipedia.org/"> Wikipedia </ulink> 
     12dé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>  
    2213 
    23 <para> &slony1; has run into a number of race conditions during its history: 
     14Dans les applications informatiques, les situations de compétitions arrivent la plupart du temps  
     15au sein des applications distribuées ou multiprocesseurs lorsque différentes partie  
     16de l'application dépendent de certains éléments partagé; si ce partage 
     17est mal géré, des confusions (erreurs !) apparaissent. Plus précisément, 
     18cela impliquent en général les situations où l'état de partage peut  
     19être changé entre le moment ou il est vérifié et le moment ou il est utilisé. 
     20</para> 
     21 
     22<para> &slony1; a connu un certain nombre de situations de compétition au cours de son histoire : 
    2423 
    2524<itemizedlist> 
    2625 
    27 <listitem><para> <xref linkend="stmtmoveset"> had, during the 1.0 and 
    28 1.1 branches, the problem that nodes did not have any way to prevent 
    29 them from processing <command>SYNC</command> events from the new 
    30 origin node (which their state would cause them to consider a mere 
    31 provider, and therefore <emphasis>not</emphasis> a source of 
    32 replicable data) before recognizing the role change from subscriber to 
    33 provider. </para> 
     26<listitem><para> Entre la version 1.0 et la version 1.1, 
     27   <xref linkend="stmtmoveset"> a avait un problÚme car les noeuds n'avait  
     28     aucun moyen d'empêcher le traitement des événements <command>SYNC</command> 
     29     en provenance du noeud origine ( qu'ils considéraient comme un simple fournisseur, 
     30     et pas comme une source de données à répliquer) avant de reconnaître le changement 
     31     de rÃŽle ( d'abonné à fournisseur ).</para> 
    3432 
    35 <para> This was fixed by introducing a new <command>ACCEPT 
    36 SET</command> event that would be submitted by the new origin; this 
    37 allowed subscribers to be aware of their need to wait for the 
    38 <command> MOVE SET </command> event.</para> </listitem> 
     33<para> Ceci fût corrigé en introduisant un nouvel événement <command>ACCEPT 
     34SET</command> qui était soumis par le nouveau noeud origine; Ceci permettait 
     35aux abonnés d'être conscients qu'il devait attendre l'événement  
     36<command> MOVE SET </command>.</para> </listitem> 
    3937 
    40 <listitem><para>In a number of places, &slony1; has the SQL 
    41 <command>lock table sl_config_lock;</command> in order to prevent race 
    42 conditions while changing the sl_log_status sequence value. </para> 
     38<listitem><para>Dans un certain nombre d'endroits, &slony1; utilise la commande 
     39    SQL <command>lock table sl_config_lock;</command> afin d'éviter les  
     40    situations de compétitions lorsque la valeur de la séquence  
     41    sl_log_status est changée. </para> 
    4342</listitem> 
    4443 
    45 <listitem><para> The &lslon; option <xref 
    46 linkend="slon-config-sync-interval-timeout"> is used to prevent a 
    47 possible race condition in which the action sequence is bumped by the 
    48 trigger while inserting the log row, which makes this bump is 
    49 immediately visible to the sync thread, but where the resulting log 
    50 rows are not visible yet. </para> </listitem> 
     44<listitem><para> L'option &lslon; <xref 
     45linkend="slon-config-sync-interval-timeout"> est utilisée pour éviter les situations  
     46      de compétition dans lesquelles la séquence d'action est dégagée par le trigger 
     47      au moment de l'insertion de ligne de log, ce qui rend le <quote>dégagement</quote> immédiatement 
     48      visible au processus de synchronisation, alors que la ligne de log correspondante 
     49      n'est pas encore visible. </para> </listitem> 
    5150 
    52 <listitem><para> The <quote>snapshot visibility</quote> approach used 
    53 by &slony1; to determine what replicated data is to be associated with 
    54 a specific <command>SYNC</command> avoids race conditions that would 
    55 be associated with trying to purely use timestamps or ID ranges to 
    56 determine what data is to be replicated.  </para> </listitem> 
     51<listitem><para> L'approche dite de  <quote>visibilité des images</quote> 
     52    utilisée par &slony1; pour déterminer quelle donnée répliquée doivent  
     53    être associée avec un <command>SYNC</command> spécifique, évite les  
     54    situations de compétition qui se produisent lorsque l'on essaie d'utiliser 
     55    simplement des timestamps ou des plages d'identifiants pour déterminer 
     56    quelles données doivent être répliquées.  </para> </listitem> 
    5757 
    58 <listitem><para> In the 1.2 branch, up to version 1.2.11, which fixed 
    59 this, <link linkend="logshipping"> log shipping </link> had a race 
    60 condition where any time configuration is reloaded by the &lslon; (as 
    61 takes place with a number of events, notably <xref 
    62 linkend="stmtsubscribeset"/>), there was a risk of the 
    63 <command>SYNC</command> IDs used to ensure proper ordering and 
    64 application of log shipping archive log files being off by one. 
    65 </para> 
     58<listitem><para> Dans la branche 1.2, jusqu'à la version 1.2.11,  
     59    qui corrige ce bug, le <link linkend="logshipping"> log shipping </link> 
     60    avait une situation de compétition où chaque fois que la configuration 
     61    était rechargée par le &lslon; ( comme cela arrive souvent, notamment avec 
     62    linkend="stmtsubscribeset"/>), il y avait un risque que les identifiant de  
     63  <command>SYNC</command> utilisé pour l'ordonnancement correct et pour l'exécution 
     64  du log shipping soient décalées d'une unité.</para> 
    6665 
    67 <para> This was resolved in 1.2.11 by moving the ID number from an 
    68 in-memory variable (susceptible to all sorts of troubles) to being 
    69 managed, transaction-safe, in the subscriber database. </para> 
     66<para> Ceci fut corrigé dans la version 1.2.11 en transformant le numéro d'identifant, 
     67  qui était un variable située en mémoire (donc génératrice de problÚmes ) en un donnée 
     68  transactionnelle, stockée dans la base de donnée de l'abonné.</para> 
    7069 
    71 <para> The problem was never exposed by the <link linkend="testbed"> 
    72 test bed framework, </link> nicely demonstrating the common finding 
    73 that race conditions are frequently highly dependent on patterns of 
    74 data input or of application timing. </para> 
     70<para> Ce problÚme ne fut jamais découvert lors des <link linkend="testbed"> 
     71bancs d'essai, </link> démontrant joliment que les situations de compétitions 
     72sont souvent trÚs dépendantes du type de données stockée ou du rythme de l'application. </para> 
    7573</listitem> 
    7674 
    …… 
    8078 
    8179</sect1> 
    82  
    83 <!-- Keep this comment at the end of the file 
    84 Local variables: 
    85 mode:sgml 
    86 sgml-omittag:nil 
    87 sgml-shorttag:t 
    88 sgml-minimize-attributes:nil 
    89 sgml-always-quote-attributes:t 
    90 sgml-indent-step:1 
    91 sgml-indent-data:t 
    92 sgml-parent-document:"slony.sgml" 
    93 sgml-exposed-tags:nil 
    94 sgml-local-catalogs:("/usr/lib/sgml/catalog") 
    95 sgml-local-ecat-files:nil 
    96 End: 
    97 -->