choisir un niveau d'isolation

**Madfrix** · 03/02/2011, 00h31

Bonjour,

dans l'optique de monter un petit projet perso (qui veut donc dire que j'ai le temps de réfléchir au préalable), je me mets à PostgreSQL (je commence à lâcher MySQL...). Je m'intéresse aux niveaux d'isolations des transactions. J'ai compris que le niveau de base Uncommited Read est permissif et peut provoquer des erreurs d'intégrité. En fait, à lire la doc, seul le niveau Serializable est 100% sur mais les transactions sont mises en attente "FIFO".

Basiquement, je me dis : utilise le mode Serializable dugenou sinon tu risques à terme de pourrir un peu ta base ! Mais je me doute que c'est pas aussi simple que cela

J'ai lu (en diagonale j'avoue) le papier d'SQLPro sur les niveaux d'isolations mais je ne comprends pas trop au final comment choisir tel ou tel niveau d'isolation...

En Uncommited Read, on s'expose quand même à terme à des incohérence non...?

Merci de m'éclairer un peu

**estofilo** · 04/02/2011, 14h04

Pour savoir si le niveau d'isolation par défaut ne convient pas, il faut identifier un scénario précis de processus concurrents travaillant sur les mêmes données en même temps.
Ce scénario dépend complètement de l'application et de son usage en parallèle ou pas.

**Madfrix** · 05/02/2011, 10h27

Bonjour et merci de la réponse.

En fait, ma bdd (non construite pour le moment), modélisera un jeu ou chaque joueur possédera des ressources. Les joueurs pouvant se faire piller, on doit considérer entre autres, le fait qu'un pillage ne doit pas retirer plus d'une certaines quantité de ressources (le joueur pillé ne peut pas avoir des ressources négatives après pillage).

Or, il faudra probablement user et abuser de transactions afin de maintenir une certaine intégrité des ressources entre les joueurs etc...

Cependant, pendant ces transactions, d'autres transactions concurrentes pourront être lancées et donc je pense créer des instabilité en cas de niveau d'isolation Uncommited Read. Pour tout dire, je ne vois pas dans quel cas ce niveau d'isolation pourrait m'être utile mais comme je n'ai jamais utilisé les niveaux d'isolation et encore mois sous pg, je me pose des questions

Le niveau Serializable provoque un ralentissement assez sensible non ?

Merci de m'éclairer un peu

**estofilo** · 07/02/2011, 18h29

Il n'y a pas techniquement de raison que les transactions soient ralenties en mode sérialisé.
En revanche, elles peuvent échouer avec une erreur de sérialisation si elles veulent modifier des données qui ont été changées entre-temps par une autre transaction.
C'est-à-dire que ça ne résout pas de problème d'accès concurrent, au contraire ça provoque une erreur quand ils surviennent.
Pour gérer des accès hautement concurrents où l'on veut faire une
barrière de synchronisation, personnellement j'ai tendance à utiliser un simple update en mode d'isolation read commited normal.
Par exemple imaginons ta table des ressources avec une ligne par joueur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
begin; -- debut transaction
update ressources SET derniere_modif=now() where joueur = :1;
... tester les ressources pour le joueur en question et les augmenter/réduire etc...
commit; -- fin transaction

Avec cet update dès le début de la transaction, un premier process pourra entrer dans cette portion de code mais un deuxième sera automatiquement mis en attente au niveau de l'update tant que le premier n'a pas effectué le commit, la ligne sur laquelle porte l'update étant verrouillée jusqu'au commit.

**Madfrix** · 07/02/2011, 21h51

Envoyé par estofilo

En revanche, elles peuvent échouer avec une erreur de sérialisation si elles veulent modifier des données qui ont été changées entre-temps par une autre transaction.

J'avais lu cela aussi il me semble sur l'aide pg.

Je croyais que les transactions en mode sérialisé mettaient en attente TOUTES les transactions de tous les users mais apparemment à lire ce que tu m'écris cela met en attente les transactions uniquement d'un utilisateur en particulier c'est cela ?

Merci de m'ôter ce gros doute ^^

**estofilo** · 08/02/2011, 12h51

Je croyais que les transactions en mode sérialisé mettaient en attente TOUTES les transactions de tous les users mais apparemment à lire ce que tu m'écris cela met en attente les transactions uniquement d'un utilisateur en particulier c'est cela ?

Non, il n'y a aucune mise en attente lié au mode sérialisé.

**SQLpro** · 10/02/2011, 18h58

Envoyé par estofilo

Il n'y a pas techniquement de raison que les transactions soient ralenties en mode sérialisé.

Là mon cher ami vous dites une grosse connerie.

Le mode SERIALIZABLE oblige à un verrou exclusif sur TOUTE LA TABLE, maintenu jusqu'à la fin de la transaction !!!!!!

Alors que le niveau REPEATABLE READ nécessite un verrou exclusif que sur les lignes manipulées et maintenu jusqu'à la fin de la transaction

Enfin le niveau READ COMMITTED nécessite un verrou exclusif sur les lignes manipulée, uniquement le temps de faire l'ordre SQL et non pas toute la transaction.

Bref, mode SERIALIZABLE => aucun accès autre que la transaction en cours sur les tables et index manipulées dans la transaction.

Si c'est pas un goulet d'étranglement pour les performances, alors je démissionne !!!!

A +

**Madfrix** · 10/02/2011, 20h59

Merci bien pour toutes ces informations.

@estofilo : merci pour la clause FOR UPDATE, j'étais passé un peu vite dessus dans la doc sans comprendre vraiment son intérêt, je vais potasser cela de nouveau.

@SQLpro : merci pour ces explications. A ce que je comprends, le niveau REPEATABLE READ équivaut à poser des clauses FOR UPDATE partout implicitement où cela est nécessaire ? Si oui, ceci me chagrine (extrait de la doc off) :

Dans PostgreSQL™, vous pouvez demander un des quatre niveaux standards d'isolation de transaction. Mais, en interne, il existe seulement deux niveaux distincts d'isolation, qui correspondent aux niveaux Read Committed et Serializable. Lorsque vous sélectionnez le niveau Read Uncommitted, vous obtenez réellement Read Committed, et quand vous sélectionnez Repeatable Read, vous obtenez réellement Serializable, donc le niveau d'isolation actuel pourrait être plus strict que ce que vous sélectionnez.

est-ce donc possible d'obtenir un niveau REPEATABLE READ "réel" ou doit on passer à chaque fois par des clauses FOR...?

Merci