Transactions imbriquer et niveau d'isolation
Résolu
cs_Malkuth
Messages postés
268
Date d'inscription
samedi 22 février 2003
Statut
Membre
Dernière intervention
24 avril 2013
-
7 oct. 2006 à 15:16
cs_skweeky Messages postés 259 Date d'inscription mercredi 3 mai 2006 Statut Membre Dernière intervention 11 janvier 2010 - 22 oct. 2006 à 17:47
cs_skweeky Messages postés 259 Date d'inscription mercredi 3 mai 2006 Statut Membre Dernière intervention 11 janvier 2010 - 22 oct. 2006 à 17:47
A voir également:
- Sql transaction example
- Decimal sql ✓ - Forum C# / .NET
- Delete sql ✓ - Forum Foxpro
- Lpad sql server ✓ - Forum SQL
- Modif colonne MONEY en decimal - Forum SQL
- Sql like ✓ - Forum SQL
3 réponses
cs_skweeky
Messages postés
259
Date d'inscription
mercredi 3 mai 2006
Statut
Membre
Dernière intervention
11 janvier 2010
8
22 oct. 2006 à 17:47
22 oct. 2006 à 17:47
A moins de me tromper, je ne crois pas qu'il y ai de moyen de liberer des verrous avant la fin d'une transaction
Christian Robert - Winwise
http://blogs.developpeur.org/christian/
MCT - Database Development / Database Administration
Christian Robert - Winwise
http://blogs.developpeur.org/christian/
MCT - Database Development / Database Administration
cs_skweeky
Messages postés
259
Date d'inscription
mercredi 3 mai 2006
Statut
Membre
Dernière intervention
11 janvier 2010
8
8 oct. 2006 à 20:10
8 oct. 2006 à 20:10
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
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
cs_Malkuth
Messages postés
268
Date d'inscription
samedi 22 février 2003
Statut
Membre
Dernière intervention
24 avril 2013
4
8 oct. 2006 à 23:28
8 oct. 2006 à 23:28
Trés clair en effet mais petite précision a propos de ma premiere question :
le problème c'est par exemple : si j'ai une grosse procédure (en temps d'exec) utilisant une transaction mais que je veux pouvoir a l'intérieur effectuer une série de requette en libérant les vérous de cette suite de requette avant la fin de toute la procédure(je sait pas si c'est clair ...),existe'il une possibiliter de libérer certains vérous avant la fin d'une transaction?
le problème c'est par exemple : si j'ai une grosse procédure (en temps d'exec) utilisant une transaction mais que je veux pouvoir a l'intérieur effectuer une série de requette en libérant les vérous de cette suite de requette avant la fin de toute la procédure(je sait pas si c'est clair ...),existe'il une possibiliter de libérer certains vérous avant la fin d'une transaction?