|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : décembre 2005 Messages : 9 ![]() |
Je vais créer une table de plusieurs millions d'enregistrements. Il s'agit de requêtes qui doivent être traitées par des centaines de threads tournant sur plusieurs machines Windows.
L'application qui insère les requêtes met à 1 la colonne cState afin d'indiquer qu'il s'agit d'une nouvelle requête à traiter. Dès qu'un thread a pris en compte une requête, il met ce champ à 2 afin d'indiquer que la requête est en cours de traitement. Comment faire pour éviter que 2 threads prennent en compte la même requête alors qu'ils font tous le même SELECT pour obtenir la prochaine requête. Le LOCK de la table n'est pas envisageable pour des questions évidentes de performance. J'ai vu l'option FOR UPDATE du SELECT avec une base InnoDB mais ça ne marche pas : les autres threads vont rester bloqués jusqu'à la libération de la première requête. Une piste pourrait être de faire directement un UPDATE avec des valeurs qui permettent ensuite de retrouver l'enregistrement, mais je crains que l'UPDATE ne soit pas atomique et que plusieurs threads puissent modifier le même enregistrement. Merci de vos conseils. |
|
|
00
|
|
|
#2 |
|
Invité de passage
![]() Inscription : décembre 2005 Messages : 9 ![]() |
Je viens de trouver ces deux articles fort intéressants :
http://sqlpro.developpez.com/cours/sqlaz/techniques/ http://sqlpro.developpez.com/isolation-transaction/ Il semble qu'en mettant mes SELECT dans des transactions avec le niveau d'isolation SERIALIZABLE j'aurai résolu mon problème. Right ? |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com