RE: Transactions
Excellent. merci.
--
Patrick
"Fred.M." wrote:
> Si ta question revient à dire "peut-on imbriquer plusieurs transactions les
> unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
> dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
> verrous exclusifs !!
>
> FRED.M.
>
> "Patrick" a écrit :
> > Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
> > final et qui englobe le tout ?
> >
> > Merci.
> >
> > --
> > Patrick
> >
> >
> > "Fred.M." wrote:
> >
> > > Bonjour Patrick,
> > > La réponse est "ça dépend", et les éléments de décision sont les suivants :
> > >
> > > 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
> > > est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
> > > Donc toute mise à jour est automatiquement validée.
> > >
> > > 2.) Si en effet tu utilises les transactions :
> > > Une transaction a notamment pour but de garder les données de ta base en un
> > > état cohérent et consistant. Ainsi, si deux opérations sont indissociables
> > > fonctionnellement parlant, elles doivent se situer dans la même transaction.
> > > Ainsi si le system plante en plein milieu du processus, soit tout est validé,
> > > soit rien ne l'est.
> > > Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
> > > exemple des opérations obsolètes dans une table d'archive.
> > > a) insert into Table_Archive select * from Table_Source Where Madate...
> > > b) Delete From Table_Source where Madate....
> > > Si chacune de ces opérations sont dans des transactions différentes (donc si
> > > tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
> > > et ton b), tes données sont insérées en archive mais pas épurées de ta table;
> > > tu auras donc des données en double. Imagines que ça peut être bien pire si
> > > tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
> > > Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
> > > ces opérations dans la même transaction.
> > > CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
> > > une génération de verrous exclusifs, qui sont susceptibles de bloquer les
> > > autres sessions le temps de la transaction. Implémenter des transactions trop
> > > longues risquerait donc de ralentir ton application.
> > >
> > > CONCLUSION :
> > > - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
> > > alors en effet tu peux commiter après chaque opération.
> > > - Si a contrario fonctionnellement parlant tes opérations de ajouts /
> > > suppressions sont conditionnées entre elles, encapsulent les dans une seule
> > > et même transaction. Et s'il s'avère que cette transaction est relativement
> > > longue, alors essaie de planifier son exécution sur une période creuse (la
> > > nuit en général) pour éviter les locks.
> > >
> > > J'espère avoir été suffisamment clair dans l'ensemble.
> > >
> > > FRED.M.
> > >
> > >
> > > "Patrick" a écrit :
> > >
> > > > Bonjour,
> > > >
> > > > Je fais une succession de mises à jour d'une table qui ajoutent et
> > > > suppriment des enregistrements. J'utilise les transactions.
> > > >
> > > > Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
> > > > supression) ou bien est-ce qu'on peut faire un seul "COMMIT" Ã la fin ?
> > > >
> > > > Merci.
> > > >
> > > > --
> > > > Patrick
|