--Задание 1. Чтение и чтение
--Сформулируй, что делают две одновременные сессии, каждая выполняет SELECT * FROM users WHERE id = 1;.
--Эти две сессии из  делают следующее: запрашивают данные из таблицы users, фильтруют по id и далее выводят все столбцы. 

--Почему оба запроса могут выполниться сразу, без ожидания?
-- Потому что этим сессиям нечего ожидать, они берут данные и читают их, здесь нет никаких действий по изменению данных.

--Задание 2. Два UPDATE одного пользователя
--Опиши, что будет делать вторая сессия, пока первая транзакция не закончилась.
--Вторая сессия будет ждать пока первая транзакция завершится.

--Почему нельзя разрешить обоим UPDATE пройти одновременно?
--В таком случае не будет ясно какой именно будет конечный результат, нельзя допускать эту коллизию, все должно быть последовательно.

--Какой email в итоге останется у Alice и почему порядок COMMIT важен?
--В данном случае в конечном счете у Алисы будет второй имэйл, либо получит ошибку (если ее откатят).

--Задание 3. SELECT ... FOR UPDATE
--что будет с SELECT * FROM users WHERE id = 2;
--просто прочитает данные. Боб лишь заблокирован для изменений.

--что будет с UPDATE users SET country = 'FR' WHERE id = 2;.
--В таком случае БД зависнет (blocked) и будет ждать пока первая транзакция не исполнится.

--Задание 4. Дедлок на двух пользователях
--Объясни своими словами, почему возникает дедлок и что сделает база с одной из транзакций.
--Потому что обе транзакции держат пользователей заблокированными. БД решает конфликт и отменяют одну из них.

--Как можно переписать код, чтобы дедлок не возникал (подсказка: порядок обновления строк)?
--Код надо писать так чтобы не было такого пересечения, в данном случае пересекаются id товаров, поэтому можно переписать запрос таким образом, что было последовательность запросов соответствовала возрастающему id. 

--Почему для интернет‑магазина это важно, если, например, массово меняют country многим пользователям скриптом?
--потому что в момент замены БД может заблокировать всех пользователей, пока не завершится транзакция, а это может быть миллион строк, соответственно, другая сессия может обратиться к одному из пользователей и получится дэдлок. Поэтому если и обновлять, то лучше партиями и с увеличением id.