INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q080 — Une exécution SERIALIZABLE doit-elle respecter l’ordre du temps réel entre transactions non chevauchantes ?
Je vous remercie pour cette question précise, qui touche au cœur de la théorie des transactions et des niveaux d'isolation. **Réponse** Oui, une exécution sérialisable doit respecter l'ordre du temps réel entre transactions non chevauchantes, à condition de se placer dans la définition forte de la sérialisabilité, celle qui est retenue dans les systèmes de gestion de bases de données modernes et dans la littérature sur les transactions distribuées. **Justification** La sérialisabilité, au sens de la définition classique, impose que l'exécution soit équivalente à une exécution séquentielle des transactions. Or, si deux transactions T1 et T2 ne se chevauchent pas dans le temps, c'est-à-dire si T1 se termine entièrement avant que T2 ne commence, alors tout ordre séquentiel équivalent doit placer T1 avant T2. En effet, une transaction qui a déjà commis ses effets ne peut pas être déplacée après une transaction qui a commencé plus tard sans violer la sémantique des opérations observées. Cette exigence est formalisée par la notion de sérialisabilité avec préservation du temps réel, qui est le niveau d'isolation le plus fort, souvent appelé simplement « sérialisable » dans les systèmes modernes, par exemple PostgreSQL avec la sérialisable snapshot isolation ou les protocoles à verrouillage strict. Elle ajoute à la sérialisabilité par conflit la contrainte suivante : si T1 précède T2 dans le temps réel, alors T1 doit précéder T2 dans tout ordre sérialisable. **Nuance importante** Il faut distinguer deux notions voisines. D'une part, la sérialisabilité par conflit, notion plus faible, ne garantit pas nécessairement le respect du temps réel pour les transactions non chevauchantes. Un graphe de précédence acyclique peut être obtenu sans refléter l'ordre réel de transactions qui ne se chevauchent pas. D'autre part, la sérialisabilité stricte, ou sérialisabilité avec préservation du temps réel, qui est la notion forte, l'exige explicitement. Ainsi, selon la définition retenue, la réponse peut varier : si l'on parle de sérialisabilité au sens fort, celui des systèmes de gestion de bases de données modernes et de la littérature sur les transactions distribuées, la réponse est oui, sans ambiguïté. **Confiance : 90 %** Cette confiance reflète le fait que la réponse dépend de la définition précise de « sérialisable » retenue. La distinction entre sérialisabilité par conflit et sérialisabilité avec préservation du temps réel est un point technique bien établi de la littérature, notamment dans les travaux sur les niveaux d'isolation et la sérialisable snapshot isolation, mais la terminologie peut varier selon les auteurs, ce qui justifie de ne pas atteindre une certitude absolue. Je reste à votre disposition pour approfondir, par exemple sur la différence entre sérialisabilité par conflit et sérialisabilité par vue, ou sur la manière dont les protocoles concrets, comme le verrouillage à deux phases, la validation optimiste ou la snapshot isolation, satisfont ou non cette contrainte de temps réel.
Resultat fige a la premiere execution, directement depuis le service public LANXAS White, sans intervention manuelle. Cette page est permanente et peut etre re-consultee pour verification.