Que se passe t'il lors d'un accès concurrent en écriture dans une DB type PostegreSQL
Par exemple, 2 appli en parallèle tente d'ajouter un user, actuellement la BDD possède un user jusqu'à 10. Les 2 applis récupèrent donc cette valeur, l'incrémente de 1 chacune , et veulent écrire l'user.id 11 chacune, alors qu'en fait, l'une aurait du prendre l'id 12.
 
Comment gérer cette problématique ?

le user.id est-il de type auto incremental ? ou le calcul tu au sein de ton application ?
 
je pencherais pour la second possibilite car postgre devrait savoir gerer ca tres bien.

Si tu veux être sûr tu mets les 2 opérations dans une transaction. Par contre attention à ne pas en abuser parce que sinon ça va te créer des problèmes..

Hum c'est vrai que l'auto increment peut aider..
Mais imaginons que c'est un traitement lambda (donc pas un auto increment), mais imaginons par exemple un compteur de visiteur.
Les 2 apps lisent 1100 visiteurs, chacune ajoute un et on se retrouve pourtant qu'avec 1101 visiteurs au lieu de 1102 ..
C'est ce genre de problème que j'aimerais éviter ..

Les 2 applis tournent en parallèle me ne peuvent pas communiquer entre elle donc pas moyen de faire une transaction non ?

 
Dans ce cas la, tu es oblige de faire la synchronization au niveau de ton code. Pour la transaction, ca doit etre possible aussi, mais je ne sais pas comment faire ...

Ah si les deux applis tournent en //, c'est different ...
 
La solution que je vois dans ce cas est de locker la table pendant le traitement ...
http://www.postgresql.org/docs/8.1 [...] -lock.html

 
Les transactions se font au niveau du SGBD. L'appli ouvre une transaction, fait ce qu'elle a à faire, puis ferme la transaction. Donc pas de pb mais faut pas qu'une transaction dure trop longtemps, sinon ça va nuire aux perfs.

 
Si tu as un transaction du type :

begin tran
declare @id int
SELECT @id = max(id) FROM users
SELECT @id = @id + 1
INSERT INTO users VALUES (@id, 'toto')
commit tran

 
Avec ce type de transaction, est-on sur que que @id sera toujours different ? Mon intuition est que sans lock, on peut avoir deux fois la meme valeur ...

Je pense que ça doit dépendre des sgbd. Dans le début de la transaction, y'a effectivement peut-être à préciser le type de transaction (de type lecture, écriture dans une table, dans un enregistrement donné...).

En general pour eviter le probleme et les transactions on met l'ID dans une autre table (qui peut contenir plusieurs ID de differente tables).
 
Pour recuperer le prochain ID on fait juste un

UPDATE IDTable
    SET ID += 1
Output inserted.id
WHERE TableName = 'MyTable'

 
Sans avoir a utiliser de longue transaction on recupere l'ID qu'on viens d'incrementer.
 
C'est pour SQL Server, mais je suppose que c'est tout a fait fesable avec MySQL.
 
L'avantage de ce systeme est qu'on n'est pas obligé d'utiliser des chiffres pour l'ID, ca peut etre quasi n'importe quoi.