Fred.M. a écrit :
> Certes, mais je parlais de façon générale avec une configuration à valeur par
> défaut, à savoir avec un niveau d'isolation de la transaction à READ
> COMMITTED.

en read committed la majorité des verrous sont partagés !

A +

>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Queques petites modifis....
>>
>> Fred.M. a écrit :
>>> 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.
>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>> vérouillé en exclusif.
>>
>> Voir les papiers que j'ai écrit sur le sujet :
>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>
>>
>>
>>> 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
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************