Plutôt que transactions, vous pouvez parler du concept plus large de verrouillage, à savoir la gestion d'un accès simultané à la base de données ordonnée.
Les deux concepts sont indépendants mais souvent utilisés ensemble (en particulier la transaction tend à impliquer une certaine forme de verrouillage mais il est également possible d'introduire des verrous sans aucune transaction). La plupart des SGBD qui supportent les transactions offrent des fonctionnalités spécifiques telles que les niveaux d'isolation des transactions qui relient les deux concepts.
Le but de transactions est de gérer une série de changements à la base de données comme une seule opération. De cette façon, si l'une des étapes associées à ces changements échouait, SQL serait en mesure de "revenir" sur toutes les modifications effectuées dans le cadre de la transaction. Ceci est important pour garantir l'intégrité référentielle de la base de données. Par exemple, pour empêcher l'ajout d'un nouvel enregistrement d'employé à la base de données, mais en omettant d'associer cet enregistrement dans la table de paie. ;-)
Le but de verrouillage, à savoir de spécifier une liste particulière de temporaires des règles qui empêchera les autres utilisateurs du SGBD aux parties l'accès (pour l'écriture, et peut-être pour la lecture) de la base de données associée à opérations CRUD particulières (opérations qui modifient le contenu de la base de données). L'idée est d'empêcher Alice et Bob d'essayer de diminuer le niveau de stock de soda pour le bureau en même temps. Ils (les instructions SQL qu'ils exécutent réellement), pourraient lire le montant actuel d'une marque de soda donnée, décrémenter cette valeur de la quantité qu'ils ont pris juste et stocker le nouveau montant dans la base de données. Comme ils lisent tous les deux la même valeur d'origine, la modification effectuée par la première de ces deux instructions SQL à compléter sera remplacée par la dernière. Les verrous (ou niveaux d'isolation des transactions) peuvent être difficiles à configurer en raison de leur impact sur le débit du serveur SQL. Fondamentalement, peut entraîner l'arrêt d'une requête particulière et attendre que le verrou soit libéré. Il existe différents types de verrous: niveau de ligne, niveau de table, etc. et également write-lock ou read_and_write_lock. On peut imaginer que si toutes les parties utilisant un serveur SQL devaient se verrouiller au niveau de la table pour toutes les requêtes qu'ils exécutaient, le nombre d'utilisateurs pouvant être servis diminuerait considérablement. Dans certains cas, cela se produit, c'est-à-dire lorsqu'une instruction SQL particulière verrouille une section particulière d'une table, mais attend ensuite qu'une autre requête se termine et supprime son verrou sur une autre table. Si l'autre requête elle-même attend que la première requête enlève son verrou sur la première table, nous avons une situation circulaire qui durerait indéfiniment (et empêcherait encore d'autres requêtes d'accéder aux données associées à ces deux verrous!)
Plus d'info: Pour MySql
Note: tous les moteurs de stockage dans les transactions de soutien de MySq1.
Transaction Isolation Levels
Locks with InnoDB store
Pour SqlLite
SqlLite transaction syntax
Avec le niveau de transaction SqlLite est définie par la différée, immédiate et exclusifs mots-clés.
Ainsi, les transactions sont-elles destinées à l'écriture sécurisée, à la lecture et à l'écriture sécurisées? –
c'est correct. Nous n'utilisons généralement pas de transaction pour lire des données (bien que nous puissions émettre des verrous, mais c'est généralement une mauvaise idée, dans un environnement fortement utilisé. – mjv