Annonce
Pour sa 21ème année, l’association GeoRezo a toujours besoin de vous !
10€ = 1 mois de frais bancaires ; 15€ = 12 mois de nom de domaine ; 30€ = 1 semaine de location des serveurs …
Retrouver nos membres bienfaiteurs
#1 Mon 20 June 2022 22:36
- EliseWi
- Participant occasionnel
- Date d'inscription: 16 May 2022
- Messages: 16
Gerer les modifications simultanees Postgresql/Postgis
Bonjour à tous,
Je travaille actuellement sur une base de données Postgres (en utilisant PgAmin 4). Je m'interroge sur la gestion des connexions simultanées et les modifications d'une même entité par différents utilisateurs en même temps. Je me suis informée sur les différentes solutions tels que les verrous et l'isolation des transactions, ainsi que la solution directe dans les paramètres de Qgis présentée dans ce post https://georezo.net/forum/viewtopic.php?id=126396 (les personnes utilisant la base le faisant principalement directement sur Qgis). Je ne suis pas vraiment sure d'avoir bien compris les principes de verrous et transactions.
Y-a-t'il un moyen de généraliser par exemple le fait que tous les updates soient sérialisables dans une base de données? De ce que j'ai compris, il faut indiquer dans la transaction directement qu'elle est sérialisable. Y a-t'il un moyen de dire que si 2 utilisateurs lancent chacun un update à quelques secondes de suite, alors il faut que le premier update soit finit pour que le deuxième se lance ? Sans qu'ils aient besoin de le spécifier dans une transaction.
Merci d'avance pour vos réponses et n'hésitez pas à me dire si je n'ai pas été claire 
Bonne journée !
Hors ligne
#2 Sun 10 July 2022 11:56
- Mathieu Denat
- Participant actif
- Lieu: Montpellier
- Date d'inscription: 5 May 2010
- Messages: 110
Re: Gerer les modifications simultanees Postgresql/Postgis
Bonjour,
La question est claire!
Y-a-t'il un moyen de généraliser par exemple le fait que tous les updates soient sérialisables dans une base de données? De ce que j'ai compris, il faut indiquer dans la transaction directement qu'elle est sérialisable. Y a-t'il un moyen de dire que si 2 utilisateurs lancent chacun un update à quelques secondes de suite, alors il faut que le premier update soit finit pour que le deuxième se lance ? Sans qu'ils aient besoin de le spécifier dans une transaction.
C'est normalement le fonctionnement par défaut.
Si A lance un update, B doit attendre la fin de la transaction pour que son update démarre.
Des problèmes peuvent survenir si A et B modifient les mêmes entités et les mêmes atttributs (les entités modifiées sont dans le "cache" de qgis de B), dans ce cas ce serait B qui écrase les modifications de A, uniquement sur les entités modifiées par A et B.
Celles modifiées uniquement par A et celles modifiées uniquement par B sont inscrites en base comme A ou B le souhaite.
Relisez bien ce dernier post qui indique un comportement qui répondra peut-être à vos besoins.
Par ailleurs, si votre volume de données modifiées est faible, que vos données ne sont pas spécialement sensible et que votre nombre d'utilisateur est relativement faible. Je pense que vous pouvez vous contenter du fonctionnemment par défaut de qqgis/postgres.
La probabilité que 2 utilisateurs modifient en même temps (à la fraction de seconde près) la même entité étant très faible.
C'est peut-être une non-solution intellectuellement non satisfaisante, mais ça peut-être un gain de temps réel (pas de paramétrage à faire) face un risque très faible!
Pour information avec peu d'utilisateurs (5) et un petit volume de données (160 000 environ, mais rarement + de 100 modifiées en même temps) je n'ai jamais eu à ma poser cette question! 
Je laisse les vrais pros vous répondre si besoin de mettre en place un système plus "rigoureux".
Et dans tous les cas, je vous conseille de tester le comportement par défaut pour voir s'il vous convient!
Mathieu
C'est en forgeant qu'on devient forgeron
Hors ligne
#3 Tue 12 July 2022 10:24
- EliseWi
- Participant occasionnel
- Date d'inscription: 16 May 2022
- Messages: 16
Re: Gerer les modifications simultanees Postgresql/Postgis
Bonjour,
Merci beaucoup pour votre réponse super claire et complète ! Qgis continue à me surprendre !
Hors ligne
