sql - niveau - read_committed_snapshot



Comment savoir quand un schéma de transaction est sérialisable? (2)

J'étudie SQL et j'ai besoin de savoir si un certain schéma de transaction est sérialisable. Je comprends la méthode de déterminer ceci est en train de faire un graphique avec les transactions en tant que nœuds et la direction entre les nœuds et si le graphique est cyclique alors le schéma n'est pas sérialisable. Mais qu'est-ce que cela signifie et qu'est-ce qui détermine s'il y a un bord dirigé dans le graphique d'une transaction à l'autre? La sérialisation est-elle dans ce cas le même type de sérialisation que l'écriture d'objets sur le disque?

Merci pour tout commentaire


La sérialisation des transactions n'a rien à voir avec la sérialisation des objets. Le niveau d'isolement de transaction sérialisable, lorsqu'il est entièrement implémenté, garantit que le comportement de tout ensemble de transactions sérialisables simultanées est cohérent avec une séquence d'exécution série (une à la fois) - comme si les transactions avaient été exécutées une à une temps. Cela signifie que si vous pouvez montrer qu'une transaction de base de données va bien faire quand elle est exécutée seule, elle fera le bon choix dans n'importe quelle combinaison de transactions sérialisables, ou elle retournera avec un échec de sérialisation pour qu'elle puisse être rejugée dès le début.

L'isolation des transactions sérialisables peut être appliquée de plusieurs façons. Le schéma le plus courant est le verrouillage strict à deux phases (S2PL). Celui-ci est si commun que vous voyez souvent des réponses sur SO qui discutent des choses seulement en termes de cette technique. Il existe également des contrôles OCC (Optimistic Concurrency Concurrence), SSI (serializable snapshot isolation) et autres.

Les versions de PostgreSQL antérieures à la version 9.1, MS SQL Server dans certaines configurations et toutes les versions d'Oracle ne fournissent pas réellement de transactions sérialisables. Ils vous permettent de les demander, mais fournissent en réalité un isolement instantané. Les versions de PostgreSQL commençant par 9.1 utilisent SSI lorsqu'une isolation de transaction sérialisable est demandée.

Il n'est pas possible de discuter en profondeur de la façon dont l'une de ces techniques fonctionne dans une réponse SO, mais de résumer les techniques mentionnées ci-dessus:

  • Sous S2PL chaque écriture dans une transaction acquiert un verrou qui ne peut être partagé avec rien, et chaque lecture dans la transaction acquiert un verrou qui peut être partagé avec d'autres lectures mais ne peut pas être partagé avec une écriture. Les verrous de lecture doivent couvrir les "trous" dans les index numérisés. Les verrous sont conservés jusqu'à la fin de la transaction et libérés de manière atomique, le travail de la transaction devenant visible pour les autres transactions. Si le blocage crée un cycle, cela s'appelle un "blocage" et l'une des transactions impliquées dans le cycle est annulée.

  • Sous OCC, une transaction garde la trace des données qu'elle a utilisées, sans les verrouiller. Lorsque la validation de transaction est demandée, la transaction vérifie si une autre transaction a modifié l'une de ses données et a été validée. Si c'est le cas, la demande de validation échoue et le travail est annulé.

  • Sous SSI écrit bloc l'un l'autre, mais les lectures ne bloquent pas les écritures et les écritures ne bloquent pas les lectures. Il existe un suivi des dépendances en lecture-écriture pour rechercher des modèles de visibilité qui créeraient un cycle dans l'ordre apparent d'exécution. Si une "structure dangereuse" est trouvée, ce qui signifie qu'un cycle dans l'ordre apparent d'exécution est possible, l'une des transactions impliquées dans le cycle possible est annulée. C'est plus comme OCC que S2PL, mais il n'y a pas autant de rollbacks dans des conflits plus élevés.

Divulgation complète: j'ai fait équipe avec Dan RK Ports of MIT pour implémenter les nouvelles transactions sérialisables basées sur SSI dans PostgreSQL 9.1.


La sérialisation signifie que la transaction peut être exécutée de manière sérielle, l'une après l'autre (rien à voir avec la sérialisation des objets), fondamentalement une transaction sérialisable si, quel que soit l'ordre dans lequel ils sont entrelacés, le résultat sera comme s'ils étaient exécutés en série. Ainsi, si le graphique est cyclique, alors il n'est pas sérialisable et il y a un risque de conflit, voici où votre niveau d'isolement aidera à décider si la transaction doit être exécutée de manière sérielle, d'abord l'une puis l'autre ou il devrait essayer de l'exécuter de manière entrelacée en espérant qu'il n'y a pas de conflits. Ce n'est pas une réponse complète mais j'espère que cela aidera.





transactions