Non, je ne pense pas que vos stipulations aboutissent à un système que nous devrions considérer sérialisable.
L'isolement d'instantané est une technique qui garantit qu'une transaction voit le même ensemble de données tout au long de la transaction. L'isolement de cliché offre certaines garanties mais ne définit pas toutes les caractéristiques nécessaires pour comprendre comment les transactions fonctionnent réellement (sauf si nous choisissons de confondre l'isolement de cliché et MVCC).
L'isolement de cliché est le plus souvent implémenté à l'aide de MVCC, Multi Version Consistency Control. MVCC définit plus en détail les transactions dans le contexte de leurs instantanés: il est dit qu'elles ne nécessitent d'isolement qu'en cas de conflit d'écriture (emplacements uniquement, ou, emplacements + valeurs, selon l'implémentation). MVCC fournit un modèle de cohérence détendu et souffre d'un biais d'écriture.
Les modèles de cohérence détendue sont difficiles à comprendre car ils sont comme un hybride entre l'absence d'isolement et l'isolement complet.
Commençons donc par un modèle de concurrence stricte en premier. Deux transactions doivent être isolées l'une de l'autre si l'une écrit sur des données que l'autre lit ou écrit (et vice versa ...).
Lorsque nous ne savons pas pourquoi une transaction lit des données, nous devons présumer qu'une valeur différente lue peut modifier le comportement du client impliqué, c'est pourquoi la condition de chevauchement des transactions indique l'isolement. Sans isolement, une lecture de données périmées dans un instantané peut facilement présenter une cohérence détendue, un autre terme pour lequel il s'agit d'incohérence, c'est-à-dire d'erreur.
Nous devons seulement considérer les données exactes lues ou écrites par les transactions, aucune donnée en dehors de cet ensemble n'a besoin d'être prise en compte. Cependant, il est essentiel de réaliser que lorsque nous parlons de données lues par une transaction, nous devons nécessairement inclure toutes les "métadonnées" (et les données et métadonnées lues par des métadonnées telles que la vérification des contraintes). Des exemples de métadonnées sont / les opérations de métadonnées sont: l'identification d'une nouvelle clé primaire unique; un autre est la somme d'une colonne entière; une autre consiste à rechercher quelque chose et à ne pas le trouver; recherches de gamme ou sommes. Cela va au commentaire de @ Matthew sur la prévention des doublons, ainsi qu'à la réponse de @Tersosauros, dans laquelle il considère l'état.
Par exemple, cela signifie que deux transactions se chevauchent (nécessitent une isolation) lorsqu'elles insèrent toutes deux une ligne (en supposant une contrainte de clé primaire unique) car la vérification de la contrainte de clé est synonyme de lecture de la colonne de clé primaire entière. Comme autre exemple, rechercher quelque chose et le trouver, c'est comme lire cette valeur, mais ne pas le trouver, c'est comme regarder chaque valeur de la colonne.
MVCC protège uniquement contre les écritures qui se chevauchent ou sont en conflit, mais ne protège pas contre les lectures (sauf si elles sont également écrites par cette transaction). Ainsi, pour obtenir une erreur de cohérence dans MVCC, tout ce que nous devons faire est de lire quelque chose qui est modifié par une autre transaction (où l'autre transaction se produit après que l'instantané de l'ancien est obtenu, mais se valide en premier), tandis que l'autre transaction continue d'utiliser des données périmées et prend toute décision différemment sur la base de ces données périmées par rapport à ce qu'il aurait fait des données à jour. C'est plus facile à provoquer que vous ne le pensez.
La cohérence détendue est une autre façon de dire potentiellement incohérente ou sujette aux erreurs. (La cohérence décontractée ne doit pas être confondue avec la cohérence éventuelle, qui est une autre forme d'erreurs populaire différente de "NoSQL".)
Sur votre question, lorsque vous dites que les transactions ne doivent jamais s'étendre sur plus d'un objet, cela doit s'appliquer aux lectures et aux écritures, ainsi qu'aux métadonnées (et aux métadonnées), y compris la vérification de cohérence, les agrégats de colonnes entières, les vérifications d'absence, les recherches de plage, etc. .: si oui, alors jusqu'ici tout va bien.
Pourtant...
J'en déduis de votre question que vous utilisez l'isolement d'instantané (MVCC) sur des objets individuels (disons plutôt que le verrouillage d'objet). (Vous mentionnez également CAS; j'ai entendu parler de comparaison et d'échange, et de test et de réglage, mais pas de contrôle et de réglage, même si je suppose que c'est similaire).
La rédaction de votre question me suggère que les "objets" ont plus d'un champ, sinon les stipulations de la question seraient inutiles.
Par conséquent, étant donné que vos objets gérés par un instantané / gérés par MVCC ont plusieurs champs, vous êtes enclin à écrire un biais dans des objets uniques. Si deux transactions mettent à jour le même objet en même temps, on peut lire un champ de la valeur de l'objet rendu obsolète par une autre transaction simultanée sur le même objet, et continuer sans savoir, donc, l'incohérence potentielle (aka erreur).
Vous pouvez utiliser le verrouillage d'objet à la place, ce qui empêcherait deux transactions (pour la mise à jour) de même regarder le même objet si une autre transaction était déjà en train de le faire.
Je crois qu'une autre forme d'isolement de cliché peut être effectuée sans utiliser le modèle de comparaison en écriture uniquement cassé de MVCC. Ainsi, vous pouvez (algorithmiquement) promouvoir l'ensemble de comparaison à partir de l'écriture seule pour inclure également l'ensemble de lecture. Ensuite, deux transactions mettant à jour le même objet ne seraient pas en mesure de provoquer un décalage d'écriture (car celle qui tenterait de valider plus tard serait abandonnée). Je pense que cela peut être la solution appropriée au problème que vous décrivez, car vous obtenez déjà la plupart des avantages que MVCC nous achèterait, en empêchant les transactions multi-objets.
(Nous devons seulement considérer les éléments / champs exacts et spécifiques lus ou écrits, mais nous devons inclure ceux lus en tant que métadonnées, potentiellement pendant les méta-opérations pour éviter un biais d'écriture (c'est-à-dire une erreur). Si nous supprimons le jeu de lecture du jeu de comparaison , ou si nous ne prenons pas en compte les métadonnées (potentiellement utilisées par les méta-opérations), nous avons alors un modèle qui permettra l'erreur.)