VPF::Надёжность транзакций, спорные ситуации.

animegirl

Дата 23.3.2013, 06:27 (ссылка)

(нет голосов)

Загрузка ...

Незнайка на Марсе

Профиль
Группа: Участник
Сообщений: 326
Регистрация: 24.7.2011

Репутация: нет
Всего: нет

Как я уже выяснила, у транзакций нету проблем, с авто инкрементом, счётчик накручивает вне зависимости от того, вставили в итоге значения или нет, это всё хорошо сделано. Я немного запуталась с дубликатами. Вот текст из мануала:

Цитата

INSERT sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.

Prior to inserting the row, a type of gap lock called an insertion intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that attempt to insert values of 5 and 6 each lock the gap between 4 and 7 with insert intention locks prior to obtaining the exclusive lock on the inserted row, but do not block each other because the rows are nonconflicting.

If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock. This can occur if another session deletes the row. Suppose that an InnoDB table t1 has the following structure:

Код


CREATE TABLE t1 (i INT, PRIMARY KEY (i)) ENGINE = InnoDB;

Now suppose that three sessions perform the following operations in order:

Session 1:

Код


START TRANSACTION;
INSERT INTO t1 VALUES(1);

Session 2:

Код


START TRANSACTION;
INSERT INTO t1 VALUES(1);

Session 3:

Код


START TRANSACTION;
INSERT INTO t1 VALUES(1);

Session 1:

Код


ROLLBACK;

The first operation by session 1 acquires an exclusive lock for the row. The operations by sessions 2 and 3 both result in a duplicate-key error and they both request a shared lock for the row. When session 1 rolls back, it releases its exclusive lock on the row and the queued shared lock requests for sessions 2 and 3 are granted. At this point, sessions 2 and 3 deadlock: Neither can acquire an exclusive lock for the row because of the shared lock held by the other.

A similar situation occurs if the table already contains a row with key value 1 and three sessions perform the following operations in order:

Session 1:

Код


START TRANSACTION;
DELETE FROM t1 WHERE i = 1;

Session 2:

Код


START TRANSACTION;
INSERT INTO t1 VALUES(1);

Session 3:

Код


START TRANSACTION;
INSERT INTO t1 VALUES(1);

Session 1:

Код


COMMIT;

The first operation by session 1 acquires an exclusive lock for the row. The operations by sessions 2 and 3 both result in a duplicate-key error and they both request a shared lock for the row. When session 1 commits, it releases its exclusive lock on the row and the queued shared lock requests for sessions 2 and 3 are granted. At this point, sessions 2 and 3 deadlock: Neither can acquire an exclusive lock for the row because of the shared lock held by the other.

1. я правильно поняла, что если одна транзакция начала вставку, то остальные ждут так или иначе?
2. я не совсем поняла, если первая транзакция делает откат (пример первый), то остальные всё равно обламываются, хотя место дубликата ещё не занято?
3. Во втором примере первая транзакция подтверждается, и связи со спорной ситуацией (как-то так перевела), транзакции 2 и 3 обе обламываются со вставкой, хотя вроде бы дубликата в самой таблице нету?

--------------------

Скажи миру - НЯ!

animegirl

Дата 24.3.2013, 09:55 (ссылка)

(нет голосов)

Загрузка ...

Незнайка на Марсе

Профиль
Группа: Участник
Сообщений: 326
Регистрация: 24.7.2011

Репутация: нет
Всего: нет

--------------------

Скажи миру - НЯ!

tzirechnoy

Дата 25.3.2013, 09:14 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 3
Всего: 16

Казалось бы, дело пяти минут -- проверить.

Akina

Дата 25.3.2013, 09:39 (ссылка)

(нет голосов)

Загрузка ...

Советчик

Профиль
Группа: Модератор
Сообщений: 20581
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 106
Всего: 454

1) Да
2) И да, и нет.
3) И да, и нет.

По 2 и 3 - разберитесь, наконец, что такое deadlock...

--------------------

О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

Zloxa

Дата 25.3.2013, 11:01 (ссылка)

(нет голосов)

Загрузка ...

Чо?

Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 33
Всего: 161

animegirl, в обоих ситуациях кейса два и три облом идет по дедлоку(взаимной блокировки) а не по задвоенному значению индеска. Таки анализировать код ошибки да - надо. smile

--------------------

Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile

animegirl

Дата 26.3.2013, 09:01 (ссылка)

(нет голосов)

Загрузка ...

Незнайка на Марсе

Профиль
Группа: Участник
Сообщений: 326
Регистрация: 24.7.2011

Репутация: нет
Всего: нет

Zloxa,
То есть... если там не будет третий одинаковой транзакции, то когда первая откат сделает, вторая пройдёт без проблем?

--------------------

Скажи миру - НЯ!

Akina

Дата 26.3.2013, 09:05 (ссылка)

(нет голосов)

Загрузка ...

Советчик

Профиль
Группа: Модератор
Сообщений: 20581
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 106
Всего: 454

Если нет ничего, что мешает транзакции - само собой она пройдёт нормально...

--------------------

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| MySQL \| Следующая тема »