LINUX.ORG.RU

чудо чудное

 


0

3

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

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

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

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

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

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

Владимир

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

пиши сразу с учетом микросервисной архитектуры. там нет транзакций.

транзакции нужны для исключения гонок. причем тут микросервисная архитектура (множество инстансов которые все одно смотрят в базу)?

quester ()

Дай угадаю. Задание дала некая компания, орудующая в Лондоне в около-fintech области и зачем-то нанимающая русских?

Правильный ответ: делай локи в DAOImplementation. Но лучше держись от них подальше. Если это то, о чем я думаю, там сидят некомпетентные укурыши.

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

Дай угадаю. Задание дала некая компания, орудующая в Лондоне в около-fintech области и зачем-то нанимающая русских?

Я хз. Человек который мне это прислал не знает откуда это у него.

некомпетентные укурыши.

Явно это так.

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

потому что вменяемые люди все же используют select for update а не serializable или глобальные локи где-то в приложении (что ставит крест на масштабируемости кода) или в спец сервисе (что эквивалентно локу таблицы)

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

По условиям задачи очевидно, что нужно использовать SERIALIZABLE.

Вообще, неплохая постановка для отделения тех, кто умеет работать с важными/ценными данными, от тех, кто думает, что умеет.

anonymous ()
Ответ на: комментарий от 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

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

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

no-such-file ★★★★★ ()

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

Т.е. мы говорим - используем вот эту конкретную СУБД, но использовать ее фишки ни ни. Интересные ребята.

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

Это не «её фишки»... а впрочем, я уже объяснял. Я бы на их месте уже удивился после того, когда человек дал бы понять, что он не знает, что такое «Optimistic/Pessimistic Locking», а если бы он и после пояснения продолжил бормотать что-то про «фишки» и т.п. (см. сообщения некоторых других участников темы) — «Вы нам не подходите».

anonymous ()