25-07-2008, 01:46 PM
En fonction de ton moteur de BDD, tu as un contrôle plus ou moins poussé sur les verrous.
Tu peux par exemple spécifier dans une transaction que tu acceptes/refuses que les données non validées (uncommited) soient lues par une requête concurrente.
Chaque moteur de BDD possède son propre système mais en général ils font référence au TRANSACTION ISOLATION LEVEL.
Je prends un exemple pour t'expliquer l'impact de ce système.
Supposons que ton système utilise un CRON pour mettre à jour régulièrement le niveau de ressource des joueurs.
Ce processus travaillant sur de gros volumes, il peut être relativement lent (disons 30 secondes).
Pendant qu'il s'exécute, un joueur souhaite lancer une construction.
- Lorsque le joueur accède à sa page, on peut se permettre de le laisser lire des données "sales". Peu importe si la quantité de ressources qu'il voit n'est pas tout a fait exacte. c'est juste une consultation.
- Lorsque le joueur lance la construction, il est hors de question de se baser sur des valeurs non valides.
On doit attendre que la MAJ des ressources soit terminée avant de démarrer le processus de vérification/validation de la construction.
L'utilisation de transaction et de clauses particulière dans tes SELECT te permet de maîtriser ces problèmes de cohérence et même d'éviter des bugs parfois bien mystérieux.
Encore une fois, je te conseille fortement de te lancer dans la lecture des système de verrous/transaction supportés par le moteur de BDD que tu utilises pour mieux appréhender le problème.
Tu peux par exemple spécifier dans une transaction que tu acceptes/refuses que les données non validées (uncommited) soient lues par une requête concurrente.
Chaque moteur de BDD possède son propre système mais en général ils font référence au TRANSACTION ISOLATION LEVEL.
Je prends un exemple pour t'expliquer l'impact de ce système.
Supposons que ton système utilise un CRON pour mettre à jour régulièrement le niveau de ressource des joueurs.
Ce processus travaillant sur de gros volumes, il peut être relativement lent (disons 30 secondes).
Pendant qu'il s'exécute, un joueur souhaite lancer une construction.
- Lorsque le joueur accède à sa page, on peut se permettre de le laisser lire des données "sales". Peu importe si la quantité de ressources qu'il voit n'est pas tout a fait exacte. c'est juste une consultation.
- Lorsque le joueur lance la construction, il est hors de question de se baser sur des valeurs non valides.
On doit attendre que la MAJ des ressources soit terminée avant de démarrer le processus de vérification/validation de la construction.
L'utilisation de transaction et de clauses particulière dans tes SELECT te permet de maîtriser ces problèmes de cohérence et même d'éviter des bugs parfois bien mystérieux.
Encore une fois, je te conseille fortement de te lancer dans la lecture des système de verrous/transaction supportés par le moteur de BDD que tu utilises pour mieux appréhender le problème.
Quand on te dit qu'un projet est terminé à 90%, prépare toi pour les 90% suivant
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC