Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
9
Добавлен:
15.01.2021
Размер:
14.96 Mб
Скачать

Пример 44: взаимодействие конкурирующих транзакций

Фантомное чтение в Oracle может быть исследовано выполнением в двух отдельных сессиях следующих блоков кода:

Oracle і Решение 6.2.2.a (код для исследования аномалии фантомного чтения)

1

-- Транзакция A:

 

-- Транзакция B:

2

ALTER SESSION SET

 

ALTER SESSION SET

 

3

ISOLATION LEVEL = {УРОВЕНЬ};

 

ISOLATION LEVEL = {УРОВЕНЬ};

4

SET TRANSACTION {РЕЖИМ};

 

SET TRANSACTION {РЕЖИМ};

5

SELECT 'Tr A: ' ||

 

SELECT 'Tr B: ' ||

6

GET IDS AND ISOLATION LEVEL

 

GET IDS AND ISOLATION LEVEL

7

FROM DUAL;

 

FROM DUAL

8

SELECT 'Tr A START: ' ||

 

SELECT 'Tr B START: ' ||

9

Г FROM DUAL;

 

 

Г FROM DUAL ;

 

 

 

 

10

 

 

SELECT 'Tr B COUNT-1: '

11

 

 

GET CT FROM DUAL;

12

EXEC DBMS LOCK.SLEEP 5 ;

 

SELECT COUNT(*)

13

 

 

FROM

"subscriptions"

14

 

 

WHERE

"sb id" > 500;

15

SELECT 'Tr A INSERT: '

 

 

 

16

GET CT FROM DUAL;

 

 

 

17

INSERT INTO "subscriptions"

 

 

 

18

"sb id"

 

 

 

19

"sb subscriber",

 

 

 

20

"sb book"

 

 

 

21

"sb start"

 

 

 

22

"sb finish",

 

 

 

23

"sb is active")

 

 

 

24

VALUES 1000,

 

 

 

25

1

 

EXEC DBMS LOCK.SLEEP110);

26

1

 

 

 

27

TO DATE('2025-01-12',

 

 

 

 

 

 

 

 

28

'YYYY-MM-DD'),

 

 

 

29

TO DATE('2026-01-12',

 

 

 

30

'YYYY-MM-DD'),

 

 

 

31

'N');

 

 

 

 

 

 

 

32

 

 

SELECT 'Tr B COUNT-2: '

33

 

 

GET CT FROM DUAL;

34

EXEC DBMS LOCK.SLEEP 10);

 

SELECT COUNT(*)

35

 

 

FROM

"subscriptions"

36

 

 

WHERE

"sb id" > 5001

37

SELECT 'Tr A ROLLBACK: '

 

 

 

38

GET CT FROM DUAL;

 

EXEC DBMS LOCK.SLEEP115);

39

ROLLBACK;

 

 

 

 

 

 

 

40

 

 

SELECT 'Tr B COUNT-3: '

41

 

 

GET CT FROM DUAL;

42

 

 

SELECT COUNT(*)

43

 

 

FROM

"subscriptions"

44

 

 

WHERE

"sb id" > 5001

45

 

 

SELECT 'Tr B COMMIT: ' ||

46

 

 

GET CT FROM DUAL;

47

 

 

COMMIT;

Перед выполнением представленных выше блоков кода необходимо отключить триггер, обеспечивающий автоинкрементацию первичного ключа в таблице subscriptions (ALTER TRIGGER "TRG_subscriptions_sb_id" DISABLE), а

после проведения эксперимента — снова включить этот триггер (ALTER TRIGGER "TRG_subscriptions_sb_id" ENABLE).

Добавлять эти команды непосредственно перед и после INSERT в транзакции A нельзя, т.к. ALTER TRIGGER приводит к автоматическому подтверждению предыдущей транзакции и запуску новой.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 490/545

Пример 44: взаимодействие конкурирующих транзакций

Итоговые результаты взаимодействия транзакций таковы.

 

 

 

Уровень изолированности транзакции B

 

 

 

READ COMMITTED

SERIALIZABLE

 

 

 

READ ONLY

READ WRITE

READ ONLY

READ WRITE

 

 

READ ONLY

INSERT в

INSERT в

INSERT в

INSERT в

A

 

транзакции A

транзакции A

транзакции A

транзакции A

 

 

транзакции

READ

 

запрещён (R/O)

запрещён (R/O)

запрещён (R/O)

запрещён (R/O)

 

 

 

 

 

 

 

 

 

 

Транзакция B не

Транзакция B не

Транзакция B не

Транзакция B не

 

COMMITTED

 

 

 

получает

получает

получает

получает

 

 

 

изолированности

 

READ WRITE

доступа к

доступа к

доступа к

доступа к

 

 

запрещён (R/O)

запрещён (R/O)

запрещён (R/O)

запрещён (R/O)

 

 

 

«фантомной

«фантомной

«фантомной

«фантомной

 

 

 

записи»

записи»

записи»

записи»

 

 

READ ONLY

INSERT в

INSERT в

INSERT в

INSERT в

 

 

транзакции A

транзакции A

транзакции A

транзакции A

 

 

 

Уровень

 

 

 

 

 

 

 

READ WRITE

доступа к

доступа к

доступа к

доступа к

 

SERIALIZABLE

 

Транзакция B не

Транзакция B не

Транзакция B не

Транзакция B не

 

 

 

получает

получает

получает

получает

 

 

 

«фантомной

«фантомной

«фантомной

«фантомной

 

 

 

записи»

записи»

записи»

записи»

 

 

 

 

 

 

 

На этом решение данной задачи завершено.

'Vf Решение 6.2.2. b{434}.

В решении{434} задачи 6.2.2.a{434} в некоторых случаях мы получали ситуацию взаимной блокировки транзакций, но сейчас мы рассмотрим код, который гарантированно приводит к такой ситуации во всех трёх СУБД.

На низких уровнях изолированности транзакций у СУБД может появиться возможность избежать взаимной блокировки, потому мы используем уровень SERIALIZABLE. Исследование поведения СУБД при работе на других уровнях изолированности вам предлагается провести самостоятельно в задании 6.2.2.TSK.F{464}.

Важно отметить, что только MS SQL Server позволяет указывать приоритет транзакции, который учитывает при принятии решения о том, какая из двух взаимно заблокированных транзакций будет отменена, MySQL и Oracle принимают такое решение полностью самостоятельно.

Представленный ниже код работает по следующему алгоритму:

транзакция A обновляет первую таблицу;

транзакция B обновляет вторую таблицу;

транзакция

A пытается обновить вторую таблицу

(ряд, заблокированный

 

транзакцией B);

 

транзакция

B пытается обновить первую таблицу

(ряд, заблокированный

 

транзакцией A);

 

наступает взаимная блокировка транзакций. Рассмотрим код, реализующий этот алгоритм.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 491/545

Пример 44: взаимодействие конкурирующих транзакций

Решение для MySQL выглядит следующим образом.

MySQL

 

Решение 6.2.2.b

 

 

 

 

1

-- Транзакция A:

 

-- Транзакция B:

2

SET autocommit = 0;

 

SET autocommit = 0;

3

SET SESSION TRANSACTION

 

SET SESSION TRANSACTION ISOLATION

4

ISOLATION LEVEL SERIALIZABLE; START

LEVEL SERIALIZABLE;

 

TRANSACTION;

 

START TRANSACTION;

 

UPDATE 'books'

 

 

 

 

SET

 

'b_name' =

 

SELECT SLEEP(3 ;

8

 

 

 

CONCAT('b_name',

'.')

 

 

 

 

 

 

WHERE

'b id' = 1;

 

 

 

10

 

 

 

 

 

 

UPDATE 'subscribers'

11

SELECT SLEEP(5);

 

SET

' s_name' =

12

 

 

 

 

 

 

 

CONCAT('s_name', '.')

13

 

 

 

 

 

 

WHERE

's id' = 1

 

 

 

 

 

 

UPDATE 'subscribers'

 

 

 

15

SET

 

's_name' =

 

SELECT SLEEP(3 ;

16

 

 

 

CONCAT('s_name',

'.')

 

 

 

 

 

 

WHERE

's id' = 1;

 

 

 

 

COMMIT;

 

 

: 'books'

19

 

 

 

 

 

 

SET

'b_name' =

20

 

 

 

 

 

 

 

CONCAT('b_name', '.')

21

 

 

 

 

 

 

WHERE

'b id' = 1

 

 

 

 

 

 

 

 

22

 

 

 

 

 

 

COMMIT;

 

 

 

 

 

 

 

 

 

Решение для MS SQL Server выглядит следующим образом. Обратите внимание на строку 5, в которой для первой транзакции устанавливается повышенный, а для второй — пониженный приоритет, в силу чего СУБД всегда будет отменять вторую транзакцию, позволяя первой успешно завершиться.

MS SQL I Решение 6.2.2.b |

1

-- Транзакция A:

-- Транзакция B:

2

SET IMPLICIT_TRANSACTIONS ON;

SET IMPLICIT_TRANSACTIONS ON;

3

SET TRANSACTION ISOLATION

SET TRANSACTION ISOLATION LEVEL

4

LEVEL SERIALIZABLE;

SERIALIZABLE;

5

SET DEADLOCK_PRIORITY HIGH; BEGIN

SET DEADLOCK_PRIORITY LOW; BEGIN

 

TRANSACTION;

TRANSACTION;

 

UPDATE

[books]

 

 

 

SET

[b_name] =

WAITFOR DELAY '00:00:03';

8

 

CONCAT([b_name], '.')

 

 

 

9

WHERE

[b id] = 1;

 

 

10

 

 

UPDATE

[subscribers]

11

WAITFOR DELAY '00:00:05';

SET

[s_name] =

12

 

 

 

CONCAT([s_name], '.')

13

 

 

WHERE

[s id] = 1

14

UPDATE

[subscribers]

 

 

15

SET

[s_name] =

WAITFOR DELAY '00:00:03';

16

 

CONCAT ( [s_name] , '.')

 

 

 

 

WHERE

[s id] = 1;

 

 

 

COMMIT;

UPDATE

[books]

19

 

 

SET

[b_name] =

20

 

 

 

CONCAT([b_name], '.')

21

 

 

WHERE

[b id] = 1

22

 

 

COMMIT;

 

 

 

 

 

 

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 492/545

Пример 44: взаимодействие конкурирующих транзакций

 

Решение для Oracle выглядит следующим образом.

Oracle I Решение 6.2.2.b |

 

 

1

-- Транзакция A:

-- Транзакция B: ALTER SESSION SET

2

ALTER SESSION SET

ISOLATION_LEVEL = SERIALIZABLE; SET

3

ISOLATION_LEVEL = SERIALIZABLE;

TRANSACTION READ WRITE;

 

SET TRANSACTION READ WRITE;

 

 

 

 

UPDATE "books"

 

 

6

SET

"b_name" =

EXEC DBMS_LOCK.SLEEP(3);

 

 

CONCAT "b_name", '.')

 

 

 

 

 

WHERE

"b id" = 1;

 

 

9

 

 

UPDATE "subscribers"

10

EXEC DBMS_LOCK.SLEEP(5|;

SET

"s_name" =

11

 

 

 

CONCAT("s_name" , '.')

12

 

 

WHERE

"s id" = 1

 

 

 

 

 

UPDATE "subscribers"

 

 

15

SET

"s_name" =

EXEC DBMS_LOCK.SLEEP(3);

16

 

CONCAT "s_name", '.')

 

 

 

 

WHERE

"s id" = 1;

 

 

 

COMMIT;

UPDATE "books"

19

 

 

SET

"b_name" =

20

 

 

 

CONCAT("b_name", '.')

21

 

 

WHERE

"b id" = 1

 

 

 

 

22

 

 

COMMIT;

На этом решение данной задачи завершено.

Задание 6.2.2.TSK.A: повторить исследование, представленное в решении*434* задачи 6.2.2. a*434* и лично посмотреть на поведение всех трёх СУБД во всех рассмотренных ситуациях.

Задание 6.2.2.TSK.B: повторить исследование, представленное в решении*462 задачи 6.2.2. b*434* и лично посмотреть на поведение всех трёх СУБД во всех рассмотренных ситуациях.

Задание 6.2.2.TSK.C: написать код, в котором запрос, инвертирующий значения поля sb_is_active таблицы subscriptions с Y на N и

наоборот, будет иметь максимальные шансы на успешное завершение в случае возникновения ситуации взаимной блокировки с другими транзакциями.

Задание 6.2.2.TSK.D: провести исследование поведения MySQL в контексте аномалии неповторяющегося чтения, выполняя первую операцию в каждой транзакции в режимах LOCK IN SHARE MODE и FOR UPDATE. (см.

решение*434* задачи 6.2.2.a*434*).

Задание 6.2.2.TSK.E: провести исследование поведения MS SQL Server в контексте аномалий потерянного обновления и неповторяющегося чтения, выполняя первую операцию в каждой транзакции с использованием «табличной подсказки38» UPDLOCK (см. решение*434* задачи 6.2.2.a*434*).

Задание 6.2.2.TSK.F: повторить решение*462* задачи 6.2.2.b*434* для всех трёх СУБД в остальных поддерживаемых ими уровнях изолированности транзакций, найти такие комбинации уровней изолированности, при которых взаимная блокировка транзакций не возникает.

38 https://msdn.microsoft.com/en-us/library/ms187373%28v=sql.110%29.aspx

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 493/545

Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

6.2.3.Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

Задача 6.2.3.a{465}: создать на таблице books триггер, определяющий уровень изолированности транзакции, в котором сейчас проходит операция вставки, и отменяющий операцию, если уровень изолированности транзакции отличен от SERIALIZABLE.

Задача 6.2.3.b{469}: создать хранимую функцию, порождающую исключительную ситуацию в случае запуска в режиме автоподтверждения транзакций.

Задача 6.2.3.c{471}: создать хранимую процедуру, выполняющую подсчёт количества записей в указанной таблице таким образом, чтобы запрос выполнялся максимально быстро (вне зависимости от параллельно выполняемых запросов), даже если в итоге он вернёт не совсем корректные данные.

Ожидаемый результат 6.2.3.a.

Если операция вставки данных в таблицу books выполняется в транзакции с уровнем изолированности, отличным от SERIALIZABLE, триггер отменяет эту операцию и порождает исключительную ситуацию.

Ожидаемый результат 6.2.3.b.

Если хранимая функция оказывается вызванной в момент, когда для текущей сессии с СУБД включён режим автоподтверждения транзакций, функция должна порождать исключительную ситуацию и прекращать свою работу.

Ожидаемый результат 6.2.3.C.

Хранимая процедура должна выполнять подсчёт записей в указанной таблице в транзакции с уровнем изолированности, обеспечивающим минимальную вероятность ожидания завершения конкурирующих транзакций или отдельных операций в них.

чРешение 6.2.3.a{465}.

Для простоты (отсутствия необходимости вручную выполнять вставку) и единообразия (поддержки всеми тремя СУБД) используем AFTER-триггеры.

Таким образом, представленные ниже решения будут отличаться только логикой определения уровня изолированности транзакций, т.к. в каждой СУБД соответствующий механизм реализован совершенно особенным, несовместимым с другими СУБД, образом.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 494/545

Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

Решение для MySQL выглядит следующим образом.

MySQL

Решение 6.2.3.a (код триггера)

1

DELIMITER $$

2

 

 

 

3

CREATE TRIGGER 'books ins trans'

4

AFTER INSERT

5

ON 'books'

 

6

 

FOR EACH ROW

7

 

BEGIN

 

8

 

DECLARE isolation level VARCHAR(50 ;

9

 

 

 

10

 

SET isolation level =

11

 

(

 

12

 

SELECT 'VARIABLE VALUE'

13

 

FROM

'information schema'

14

 

 

'session variables'

15

 

WHERE

'VARIABLE NAME' =

16

 

 

'tx isolation'

17

 

);

 

18

 

 

 

19

 

IF (isolation level != 'SERIALIZABLE')

20

 

THEN

 

21

 

SIGNAL SQLSTATE '45001' SET MESSAGE TEXT = 'Please, switch your

22

 

transaction to SERIALIZABLE isolation level and rerun this

23

 

INSERT again.', MYSQL ERRNO = 1001

24

 

END IF;

 

25

 

 

 

26

 

END;

 

27

$$

 

28

 

 

 

29

DELIMITER ;

 

 

 

 

 

Проверить работоспособность и корректность представленного решения можно выполнением следующего кода: первая попытка выполнить вставку закончится исключительной ситуацией, порождённой в триггере, а вторая попытка пройдёт успешно.

MySQL і Решение 6.2.3.a (код для проверки работоспособности решения)

1SET SESSION TRANSACTION

2ISOLATION LEVEL READ COMMITTED;

4INSERT INTO 'books'

5

 

('b name',

6

 

'b_year',

7

 

'b_quanti ty')

8

VALUES

('И ещё одна книга',

9

 

1985,

10

 

2 ;

11

 

 

12SET SESSION TRANSACTION

13ISOLATION LEVEL SERIALIZABLE;

15INSERT INTO 'books'

16

 

('b name',

17

 

'b year',

18

 

'b_quanti ty')

19

VALUES

('И ещё одна книга',

20

 

1985

21

 

2 ;

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 495/545

Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

Решение для MS SQL Server выглядит следующим образом.

MS SQL і

Решение 6.2.3.a (код триггера)

[

1CREATE TRIGGER [bOoks^ins^trans] ......................................

2ON [books]

3AFTER INSERT

4AS

5DECLARE @isolation_level NVARCHAR 50 ;

6

SET @isolation_level =

8(

9SELECT [transaction_isolation_level]

10FROM [sys].[dm_exec_sessions]

11WHERE [session_id] = @@SPID

12);

13

14IF @isolation_level != 4

15BEGIN

16RAISERROR ('Please, switch your transaction to SERIALIZABLE isolation

17

level and rerun this INSERT again.', 16, 1);

18ROLLBACK TRANSACTION;

19RETURN

20END;

21GO

Проверить работоспособность и корректность представленного решения можно выполнением следующего кода: первая попытка выполнить вставку закончится исключительной ситуацией, порождённой в триггере, а вторая попытка пройдёт успешно.

MS

QL 1 Решение 6.2.3.a (код для проверки работоспособности решения)

1

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

2

 

 

 

3

INSERT INTO [books]

 

4

 

([b_name] ,

 

5

 

[b_year],

 

6

 

[b_quantity])

7

VALUES

('И ещё одна книга',

8

 

1985, 2

;

9

 

 

 

10SET TRANSACTION ISOLATION

11LEVEL SERIALIZABLE;

12

 

 

 

13

INSERT INTO [books]

 

 

 

 

14

 

([b_name],

 

 

 

 

15

 

[b_year],

 

 

 

 

16

 

[b_quantity])

 

 

 

17

VALUES

('И ещё одна книга',

 

 

 

18

 

1985, 2

;

 

 

 

19

 

 

 

20

21

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 496/545

Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

Решение для Oracle выглядит следующим образом.

Oracl

і

Решение 6.2.3.a (код триггера)

|

e

 

 

 

 

1

CREATE OR REPLACE TRIGGER "books ins trans"

2

AFTER INSERT

 

3

ON "books"

 

 

4

FOR EACH ROW

 

5

 

DECLARE

 

 

6

 

isolation level NVARCHAR2 150);

7

 

trans id VARCHAR(100 ;

 

8

 

BEGIN

 

 

9

 

trans id := DBMS TRANSACTION.LOCAL TRANSACTION ID(FALSE);

10

 

SELECT CASE BITAND "transaction" flag, POWER 2, 28 )

11

 

 

WHEN 0 THEN 'READ COMMITTED'

12

 

 

ELSE 'SERIALIZABLE'

 

13

 

 

END AS "session isolation level"

14

 

INTO

isolation level

 

15

 

FROM

v$transaction "transaction"

16

 

 

JOIN v$session "session"

17

 

 

ON "transaction" addr = "session" taddr

18

 

 

AND "session".sid = SYS CONTEXT('USERENV', 'SID');

19

 

 

 

 

20IF isolation level != 'SERIALIZABLE')

21THEN

22RAISE APPLICATION ERROR(-20001 'Please, switch your transaction

23to SERIALIZABLE isolation level and rerun this INSERT again.');

24END IF;

25

26 END;

Проверить работоспособность и корректность представленного решения можно выполнением следующего кода: первая попытка выполнить вставку закончится исключительной ситуацией, порождённой в триггере, а вторая попытка пройдёт успешно.

Oracle Решение 6.2.3.a (код для проверки работоспособности решения)

1ALTER SESSION SET

2ISOLATION_LEVEL = READ COMMITTED

3

 

 

4

INSERT INTO "books"

5

 

"b_name",

6

 

"b_year",

7

 

"b_quantity")

8

VALUES

('И ещё одна книга',

9

 

1985,

10

 

2);

11

 

 

12ALTER SESSION SET

13ISOLATION_LEVEL = SERIALIZABLE;

15INSERT INTO "books"

16

 

"b_name",

17

 

"b_year",

18

 

"b_quantity")

19

VALUES

('И ещё одна книга',

20

 

1985,

21

 

2);

На этом решение данной задачи завершено.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 497/545

Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

'ЙАЙ'

Решение 6.2.3.b{465}.

Поскольку в условии задачи не сказано, что именно должна делать функция, мы ограничимся проверкой режима автоподтверждения транзакций и порождения исключительной ситуации в случае, если он включён.

Решение для MySQL выглядит следующим образом.

MySQL I

Решение 6.2.3.b (код функции)

|

1DELIMITER $$

2CREATE FUNCTION NO AUTOCOMMIT()

3RETURNS INT DETERMINISTIC

4BEGIN

5IF ((SELECT @@autocommit) = 1

6THEN

7SIGNAL SQLSTATE '45001'

8SET MESSAGE TEXT = 'Please, turn the autocommit off. ,

9MYSQL ERRNO = 1001;

10RETURN - 1

11END IF;

12 13 -- Тут может быть какой-то полезный код :).

14

15RETURN 0;

16END$$

17

18 DELIMITER ;

Проверить работоспособность и корректность представленного решения можно выполнением следующего кода: первый вызов функции закончится исключительной ситуацией, а второй пройдёт успешно.

MySQL Решение 6.2.3.b (код для проверки работоспособности решения)

1 SET autocommit = 1;

2 SELECT NO_AUTOCOMMIT();

3

4SET autocommit = 0;

5SELECT NO AUTOCOMMIT();

Решение для MS SQL Server выглядит следующим образом.

Обратите внимание на следующие важные моменты, характерные для MS

SQL Server:

состояние автоподтверждения транзакций можно определить лишь косвенно (строки 8-23 кода);

явно породить исключительную ситуацию в коде хранимой функции невозможно, приходится использовать обходное решение (строки 27-31 кода);

отменить транзакцию в коде хранимой функции невозможно, но в силу порождения исключительной ситуации транзакция будет остановлена.

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 498/545

Пример 45: управление транзакциями в триггерах, хранимых функциях и процедурах

MS SQL I

Решение 6.2.3.b (код функции)

|

1

2

3

4

5

6

7

8

9CREATE FUNCTION NO_AUTOCOMMITT() RETURNS INT WITH SCHEMABINDING AS BEGIN

10DECLARE @autocommit INT;

11

12IF (@@TRANCOUNT = 0 AND (@@OPTIONS & 2 = 0))

13BEGIN

14SET @autocommit = 1

15END

16ELSE IF (@@TRANCOUNT = 0 AND (@@OPTIONS & 2 = 2|) BEGIN

17SET @autocommit = 0 END

18ELSE IF (@@OPTIONS & 2 = 0)

19BEGIN

20SET @autocommit = 1 END

21ELSE

22BEGIN SET @autocommit = 0

23END;

24

25IF @autocommit = 1)

26BEGIN -- В функциях MS SQL Server нельзя использовать RAISEERROR!

28

-- RAISERROR ('Please,

turn the autocommit

off.', 16, 1);

29

 

 

 

 

30

-- Обходной путь по порождению исключения: RETURN

 

31

CAST('Please, turn the

autocommit off.' AS

 

INT);

32

 

 

 

 

33

-- Отменить транзакцию

из функции в MS SQL Server тоже нельзя.

34— ROLLBACK TRANSACTION;

35END;

36 37 -- Тут может быть какой-то полезный код :).

38

39RETURN 0;

40END;

41GO

Проверить работоспособность и корректность представленного решения можно выполнением следующего кода: первый вызов функции закончится исключительной ситуацией, а второй пройдёт успешно.

MS SQL Решение 6.2.3.b (код для проверки работоспособности решения)

1SET IMPLICIT_TRANSACTIONS OFF;

2SELECT dbo NO_AUTOCOMMITT();

3

4SET IMPLICIT_TRANSACTIONS ON;

5SELECT dbo NO AUTOCOMMITT();

Работа с MySQL, MS SQL Server и Oracle в примерах © EPAM Systems, RD Dep, 2016-2018 Стр: 499/545