lit non engagés?

Question

Je regardais les problèmes de concurrence potentiels DB alors je suis allé lire. J'ai trouvé http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005267.htm il mentionne l'accès aux données non validées.

  

L'accès aux données non validées.   Une application peut mettre à jour une valeur   la base de données, et l'application B pourrait   lire cette valeur avant qu'il ne soit   engagé. Ensuite, si la valeur de A est   plus tard engagé, mais soutenu sur,   les calculs effectués par B sont   sur la base non engagée (et probablement   invalide) données.

Qu'est-ce que ... je pensais que d'autres sessions (même application et même même thread) peuvent lire des données qui n'a pas encore été commis? Je pensais que la connexion / session (je ne suis pas sûr de ma terminologie) qui a écrit les données dans la transaction non validée peut lire les données non validées.

Peut autres threads vraiment lire les données qui hasnt été commis? Je prévois d'utiliser MySQL, mais je peux utiliser SQLite

Answer 1

Quelles autres sessions peuvent lire dépend de la façon dont vous configurez votre base de données. En MySQL il dépend aussi de ce moteur base de données que vous utilisez. Le terme que vous recherchez (en ANSI termes SQL) est « niveau d'isolement » .

De nombreuses bases de données par défaut à un niveau d'isolement où se lit sur les données non validées bloqueront. Donc si la transaction Un enregistrement de mises à jour 1234 dans le tableau T et la transaction B tente de sélectionner ENREGISTRE 1234 avant une validation ou une B puis bloque jusqu'à ce que A fait une de ces choses.

Voir Transactions noreferrer MySQL, Partie II -. niveaux d'isolement de transaction

Un inconvénient grave est que les opérations de mise à jour des lots qui vivent dans les transactions de longue durée (en général) peut potentiellement bloquer de nombreuses demandes.

Vous pouvez également définir si B voir les données non validées mais qui est souvent mal conseillé.

Sinon, vous pouvez utiliser un programme appelé MVCC ( "contrôle d'accès concurrentiel Multiversion"), qui donnera différentes transactions une vue cohérente des données en fonction du moment où la transaction a commencé. Cela évite le problème de lecture non validée (lecture de données qui peuvent être annulées) et est beaucoup plus évolutive, en particulier dans le cadre des opérations à long terme.

MySQL supporte MVCC .

Answer 2

Certes, dans SQL Server, vous pouvez, vous devez choisir de le faire, est-ce pas la valeur par défaut, mais si vous utilisez le niveau d'isolation droite ou indice de requête, vous pouvez choisir de lire une ligne non engagée, cela peut aboutir à des problèmes et même une double lecture de la même ligne en théorie.

Answer 3

Cet article mentionne l'accès aux données non validées comme l'un des problèmes éliminés par le gestionnaire de base de données.

  

Les commandes du gestionnaire de base de données cette   l'accès à prévenir les effets indésirables,   tels que:

     

...

     

  
• L'accès aux données non validées.
  

moteur de stockage InnoDB de MySQL prend en charge plusieurs niveaux d'isolation des transactions. Pour plus de détails, voir http://dev.mysql.com/doc/refman/ 5.4 / fr / set-transaction.html .

Answer 4

Pour certaines versions de certaines bases de données, la mise en requêtes pour être en mesure de lire non engagés d'améliorer les performances, en raison de verrouillage réduite. Cela laisse encore des questions de sécurité, de fiabilité et d'évolutivité à répondre.

Pour donner un cadre précis, je travaillais sur un site e-commerce très grand. Ils ont utilisé lecture non validée sur lit au catalogue du magasin, car les données ont été largement accessible, rarement changé, et non sensibles aux préoccupations concernant la lecture des données non validées. Toutes les données du catalogue qui a été utilisé pour placer une commande seront revérifiés de toute façon. C'était sur SQL Server 2000, qui était connu pour avoir des problèmes de performance de verrouillage. Sur les versions plus récentes de SQL Server, les performances de verrouillage est améliorée, de sorte que ce ne serait pas nécessaire.