Salut
A) Les transactions imbriquées sont une horreur pour résumer le fonctionnement dès qu'il y a COMMIT ou ROLLBACK celà s'applique à toutes les transactions actives de la session pour le comprendre voici un petit code :
CREATE
TABLE
#t
(
clef
int
identity
(
1
,
1
)
not
null,
nom
varchar
(
10
)
not
null)
BEGIN
TRAN
A
INSERT
INTO
#t
(
Nom
)
VALUES
(
'A'
)
SELECT
*
FROM
#t
BEGIN
TRAN
B
INSERT
INTO
#t
(
Nom
)
VALUES
(
'B'
)
SELECT
*
FROM
#t
COMMIT
TRAN
B
INSERT
INTO
#t
(
Nom
)
VALUES
(
'C'
)
SELECT
*
FROM
#t
ROLLBACK
TRAN
B
INSERT
INTO
#t
(
Nom
)
VALUES
(
'D'
)
SELECT
*
FROM
#t
DROP
TABLE
#t
Il est donc impossible ou presque d'imbriquer des transactions, la seul exception étant avec un SAVE TRANSACTION XXX où un ROLLBACK XXX permet de revenir au point du SAVE mais c'est tout.
B) Le ReadCommited est le niveau par défaut, le Serializable celui-ci qui vérouille le plus les ressources, il y en a 1 entre les 2 qui est repeatable read.
- ReadCommited : Dans ce mode quand on lit on essaye d'acquérir un vérrou Partagé (S), on attend si la ressource est acctuellement en écriture, quand on obtient ce verrou on lit et on libère immédiatement après le SELECT. Quand on écrit c'est un verrou Exclusif (X) qui attend que la ressource ne soit ni lue, ni écrite, le vérrou est libéré à la fin de la transaction.
- Repeatable Read : Seule différence c'est que le vérrou (S) en lecture est libéré à la fin de la transaction. Dans ce mode quand on lit une ressource elle ne peut être modifiée par une autre transaction avant la fin de la notre.
- Serializable : Ce niveau de vérouillage est identique au précédent et en plus il interdit les insertion et suppression de données de la table. Par exemple si je séléctionne tous les enregistrements de mes clients français sur ma table, j'interdis à tout autre transaction d'inserer un client français ou d'en supprimer un.
Voilà j'expère que c'est clair.
Christian Robert - Winwise
http://blogs.developpeur.org/christian/
MCT - Database Development / Database Administration