Как стать автором
Обновить
-2
0

Пользователь

Отправить сообщение
Может в oracle напишем, что второе окно тормозит?
Видимо про подводные камни при переезде на хранение сессий в бд тоже есть смысл написать
По вашему посту видно, что работа с сервисами где учитывают деньги вас обошла стороной. Может, оно и к лучшему. Не поверите, но не просто так сделали построчную блокировку и транзакции, не только для того, чтобы были deadlock-и и второе окно тормозило. По дефолту на session file тоже ставится лок и вторая страница не открывается. Это так, на всякий случай.
именно, до смешного. Львиная доля студентов у нас знает что такое классы в яп, а вот что с ними делать понимают от силы 5%.
сначала где-то увидел что я предлагаю дергать API в рамках лока, сейчас «обернем в транзакцию неуместно». Мессадж поста «немного» не тот. не?
юзер жмет на кнопку «activate» — мы лочим баланс, холдим деньги и переведим запрос в статус TO_PROCESS

далее 2 таска:
-лок и смена статуса на что-то вроде PROCESSING + коммит + api call
-получение колбека либо опрос сервиса и перевод запроса в конечное состояние COMPLETE

но всё равноу нас должен быть либо способ узнать статус на удаленном сервисе либо получить обратный звонок от него. Иначе на любом этапе можно потерять данные, слепо дернуть api без обратной связи безопасно не получится
согласен, в такой ситуации море мест и вариантов где можно потерять данные.
не на уровне бд. а смысл похож
коммит не пройдет из-за deadlock-a? если нужные строки залочить, то всё должно пройти.
в ситуации выше хотелось лишь понять, знает ли кандидат как пользоваться одной из фич innodb а именно построчным локом.

для звонка во внешний апи вариантов тут несколько:
-до звонка уменьшить баланс и закоммититься
-без построчного лока попытаться захватить запись способом вроде " update requests set status=%pid where status=0 and id=123" и продолжить
2

Информация

В рейтинге
Не участвует
Откуда
Sydney, New South Wales, Австралия
Дата рождения
Зарегистрирован
Активность