1 Transactions et reprise sur panne

1.1 Transactions sous Oracle

Une transaction est une séquence d'ordres SQL exécutés tous ou aucun.¹
Le début d'une transaction est le premier ordre qui suit :
1. connexion au serveur, ou
2. fin de transaction.
Les fins de transaction :
1. annulation
2. confirmation (transaction dîte alors validée).
listes des confirmations :
1. explicite : commit
2. implicites :
  1. tous ordres de mise à jour de schéma
  2. commande de déconnexion du mode interactif (ou application)
  3. grant (ordre de gestion de la confidentialité, vu bientôt)
  4. en mode de confirmation automatique : toutes mises à jour de l'instance²
effet : confirme toutes mises à jour de l'instance depuis le début de la transaction
listes des annulations :
1. explicite : rollback
2. implicite : déconnexion anormale (autre qu'ordre explicite de déconnexion interactif ou application)
effet : annule toutes mises à jour de l'instance depuis le début de la transaction
remarques :
1. au cours transaction : ``table virtuelle locale'', différente de la table réelle visible par tous clients
2. un ordre peut échouer sans annuler la transaction (ex : insertion avec colonnes incorrectes)
rapport avec la persistance : une mise à jour³ persiste ssi elle fait partie d'une transaction validée
recommandations :
1. ne pas mettre dans la même transaction des mises à jour non corrélées logiquement
2. expliciter toutes les confirmations et annulations par des commit ou des rollback.

1.2 Analyse de programme

On s'intéresse ici à prévoir le contenu de la base à chaque instant au cours du déroulement d'une séquence d'ordres SQL.⁴

On considère une table t(a integer, b integer) contenant à l'origine le(s) n-uplet(s) indiqué(s) au début de chaque tableau. Tout ordre dessus est autorisé à tout utilisateur. On considère un client p₁ qui lance les séquences d'ordres suivantes, immédiatement après sa connexion, avec le mode de confirmation automatique non activé. Un autre client quelconque est représenté par p₂. Compléter les tableaux suivants. Indiquez le début et la fin de chaque transaction. Vérifiez ensuite sur machine avec sqlplus.

ordres p₁	`t` ds trans p₁	`t` vue par p₂
	`(1,2)`	`(1,2)`
`insert (3,4)`
`insert (1,2)`
`rollback`
`commit`
`insert (1,2)`
`exit`

ordres p₁	`t` ds trans p₁	`t` vue par p₂
	`(1,2)`	`(1,2)`
`rollback`
`insert (1,2)`
`alter t add (c integer)`
`update b = 3 where a = 1`
panne : tapez ctl-`\`

ordres p₁	`t` dans transaction p₁	`t` vue par p₂
	`(1,2)`	`(1,2)`
`insert (3,4)`
`insert (5,6)`
`set autocommit on`
`insert (7,8)`
`rollback`
`insert (1,2,3,4)`
`delete where a = 1`
panne : tapez ctl-`\`

1.3 Construction de programme

Il s'agit ici de gérer vous-même la reprise sur panne en plaçant les débuts et fins de transaction aux bons endroits pour préserver la cohérence de votre base en cas de panne. Faites l'exercice suivant en mode interactif, puis programmez-le sous Java. Testez dans les deux cas.

Vous arrivez dans une SSII dans laquelle on vous confie la séquence d'ordres suivante, censée gérer une situation d'achat de billet sur les tables Voyage(client, destination, km), et Banque(client, montant) :

insert into Voyages
values(Jules, Saint Lucien, 100) ;

update Banque
set montant -= 100
where client = Jules ;

Concrétisez l'exemple en considérant un ou deux n-uplets dans chaque table.
Enoncez la contrainte que doivent satisfaire les données de votre exemple.
Ce programme est-il correct ? Sinon, donnez tous les contre-exemples (pannes), en donnant à chaque fois le contenu de la base, et le déroulement du programme. Expliquez. Testez sur machine en simulant les pannes (lesquelles ? comment ?).
Réécrivez ce programme pour qu'il soit robuste aux pannes. Donnez toutes les variantes possibles. Testez sur machine en simulant les pannes.
Considérons mieux votre programme. Est-il possible qu'un des ordres échoue sans faire échouer la transaction ? Votre programme est-il donc fiable ? Indiquez intuitivement ce qu'il faudrait faire pour qu'il le devienne.⁵ Est-ce le même problème pour toutes les variantes ?