LINUX.ORG.RU

чудо чудное

 


0

3

Прислали тут левый документ с какого-то собеседования:

Тестовое задание на позицию Technical Team Leader

Задача:
- Разработать систему обработки (имитация банковской системы управления счётом)
...
- В качестве базы данных использовать PostgreSQL
...
- Регистрация нового пользователя системы с ролью «клиент»:
-- внесение средств на счёт;
-- перевод денежных средств на другой счёт;
-- вывод средств.
...
- Система должна обеспечивать консистентность данных при любых нагрузках;
...

- Запрещается использовать Optimistic/Pessimistic Locking (и другие подобные блокировки) на уровне СУБД.

Те эти ребята предлагают не использовать транзакции и select for update. Я правильно понимаю что цель этого задания в том что правильный соискатель должен отказаться писать этот говнокод и это и будет критерием сдачи задания?

★★
Ответ на: комментарий от anonymous

Не подойдёт здесь serializable, написано ж не использовать блокировки в СУБД. Хотя ты наверное думаешь, что serializable использует libastral, а не блокировки

anonymous
()
Ответ на: комментарий от anonymous

Не подойдёт здесь serializable, написано ж не использовать блокировки в СУБД.

Серьёзно? Написано было вот что:

Запрещается использовать Optimistic/Pessimistic Locking (и другие подобные блокировки) на уровне СУБД.

Хотя ты наверное думаешь, что serializable использует libastral, а не блокировки

Так что я, наверное, думаю, что тебе стоит внимательнее читать.

anonymous
()
Ответ на: комментарий от anonymous

Ну коль так, расскажи, почему реализация serializable в postgres не использует

Optimistic/Pessimistic Locking (и другие подобные блокировки)

С интересом почитаю

anonymous
()
Ответ на: комментарий от anonymous

Ну коль так, расскажи, почему реализация serializable в postgres не использует Optimistic/Pessimistic Locking (и другие подобные блокировки)

Потому что «optimistic locking» и «pessimistic locking» — это распространённые названия методов явного управления параллельным доступом из приложения, см. например: https://stackoverflow.com/a/129397

Т.е. это понятия совсем из другой оперы.

anonymous
()
Ответ на: комментарий от anonymous

Уровень изоляции serializable для транзакции приложение задаёт вполне явно. Нет разницы - выдавать команды типа lock/for update или сказать СУБД «сделай-ка само». Не стоит зацикливаться на конкретных деталях без хорошего понимания концепции

anonymous
()
Ответ на: комментарий от anonymous

Уровень изоляции serializable для транзакции приложение задаёт вполне явно.

Да и любой другой, если это не default, и что?

Нет разницы - выдавать команды типа lock/for update или сказать СУБД «сделай-ка само».

Есть. В PostgreSQL, например, сделать то, что делает SERIALIZABLE, «вручную» (на других уровнях изоляции) просто невозможно (СУБД таких средств не предоставляет).

Не стоит зацикливаться на конкретных деталях без хорошего понимания концепции

Вот именно. А суть в том, что не нужно путать автоматическое управление изоляцией транзакций с ручным.

anonymous
()
Ответ на: комментарий от anonymous

сделать то, что делает SERIALIZABLE, «вручную» (на других уровнях изоляции) просто невозможно

Заинтриговал, если честно. Можно небольшой пример?

не нужно путать автоматическое управление изоляцией транзакций с ручным

По твоей ссылке ничего не сказано об этом важном различии

anonymous
()
Ответ на: комментарий от anonymous

Заинтриговал, если честно. Можно небольшой пример?

Естественно, нельзя, ведь это невозможно! Т.е. это ты покажи мне, как ты наложишь, например, SIRead lock на что-либо вообще «вручную» на любом другом уровне изояции.

По твоей ссылке ничего не сказано об этом важном различии

Целью этой ссылки не была замена учебника по теории и практике использования СУБД. Т.е. «и что»?

anonymous
()
Ответ на: комментарий от anonymous

SIRead lock

Это детали реализации, ты опять в дебри полез. Я так понимаю, принципиальной невозможности заменить serializable на read committed + explicit locking нет

Т.е. «и что»?

То, что ты так и не смог показать, о чём тебя просили

anonymous
()
Ответ на: комментарий от anonymous

Это детали реализации, ты опять в дебри полез.

По-моему, нет. Было вот это утверждение?

Нет разницы - выдавать команды типа lock/for update или сказать СУБД «сделай-ка само».

Так вот, разница есть (как в процессе (возможности использования средств СУБД «вручную»), так и в результате — гарантированного достижения сериализуемости против «да вроде работает» в его ручной имитации). По этому пункту есть вопросы?

То, что ты так и не смог показать, о чём тебя просили

Что-что?

Вопрос был такой, напомню:

Ну коль так, расскажи, почему реализация serializable в postgres не использует Optimistic/Pessimistic Locking (и другие подобные блокировки)

По нему нужно ещё объяснять, чем отличается тёплое от мягкого?

anonymous
()
Ответ на: комментарий от anonymous

чем отличается тёплое от мягкого?

Ну да ладно, не хочешь объяснять - как хочешь

гарантированного достижения сериализуемости против «да вроде работает» в его ручной имитации

Вот я как раз просил у тебя пример этого «вроде работает». Приведи пару конкурентных, скажем, update-ов и вопрос будет снят. Пока тебя не понять

anonymous
()
Ответ на: комментарий от anonymous

Ну да ладно, не хочешь объяснять - как хочешь

Я тебе уже объяснил. Не хочешь понимать - как хочешь.

Приведи пару конкурентных, скажем, update-ов и вопрос будет снят.

Хмм... какой конкретно вопрос? Каких «скажем, update-ов», ты вообще о чём?

anonymous
()
Ответ на: комментарий от anonymous

ты вообще о чём?

Я о том, что у тебя проблема с изложением своих мыслей. Что ж, ожидаемый результат

anonymous
()
Ответ на: комментарий от anonymous

Хотя ты наверное думаешь, что serializable использует libastral, а не блокировки

Использовать он может что угодно, например общую очередь без всяких блокировок. (Насколько это эффективно — другой вопрос).

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

To guarantee true serializability PostgreSQL uses predicate locking

Нет, не что угодно - мы же не про сферическую СУБД в вакууме. А в общем случае - разумеется

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.