Смотрите внимательнее. В режиме Read Committed, про который говорится в варианте 2, закоммичены могут быть обе. Об этом говорит официальная дока:
UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the command start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found. In this case, the would-be updater will wait for the first updating transaction to commit or roll back (if it is still in progress). ... If the first updater commits, the second updater will ignore the row if the first updater deleted it, otherwise it will attempt to apply its operation to the updated version of the row. The search condition of the command (the WHERE clause) is re-evaluated to see if the updated version of the row still matches the search condition. If so, the second updater proceeds with its operation using the updated version of the row. ...
В данном случае вторая транзакция при выполнении commit(); выяснит, что да, произошло параллельное обновление с той же строкой, и попробует заново применить все операции (в данном случае 2 операции UPDATE accounts и операцию SELECT amount). Проблема в том, что проверка на неотрицательность баланса находится в Java-коде, а не в SQL, и СУБД до нее просто не дойдет, успешно закоммитив отрицательный баланс.
В вашем варианте 2 (пост-проверка на овердрафт) проблема с отрицательным балансом не решена.
На шаге 3 там сначала выполняется проверка баланса (взятого с шага 2) на неотрицательность, а потом уже коммит транзакции. Но ничего не запрещает параллельной транзакции протиснуться между проверкой баланса и коммитом. Если на счету 100 рублей, а в транзакциях А и Б запрошены переводы на 80 и 70 рублей, то возможна ситуация:
1. проверка перерасхода на шаге 3 в транзакции А 2. проверка перерасхода на шаге 3 в транзакции Б (Обе проверки пройдут, т.к. ни одно списание не закоммичено и соответственно другие транзакции их не видят) 3. коммит транзакции А 4. коммит транзакции Б
В итоге обе транзакции будут успешны, а проверки перерасхода не сработают. Баланс будет -50 рублей.
Все же с Dragon сравнивать не совсем корректно, он возвращается с низкой околоземной орбиты, а Орион — с Луны почти со второй космической скоростью. А кинетическая энергия капсулы пропорциональна квадрату скорости.
Сравнивать имеет смысл с капсулами Аполлонов скорее.
У Байконура хоть и 46 градусов широта, но нельзя с него запускать строго на запад из-за ограничений на поля падения ступеней и головного обтекателя, и траектория чуть отклоняется на север. Из-за этого наклонение орбиты МКС тоже больше, чем широта Байконура, и составляет 51,6 градуса.
Если надо сделать X в третий раз - то выполняется рефакторинг и автоматизация выполнения X
Если стоимость рефакторинга / автоматизации на 1-2 порядка превышает стоимость выполнения X, то автоматизация просто может оказаться нецелесообразной на текущем этапе (например, без понимания востребованности продукта на рынке). Также бывает, что для автоматизации нужны какие-то дополнительные ресурсы / технологии, которых сейчас нет.
Так что в теории все красиво, но на практике рутинные задачи встречаются довольно часто.
А какая мотивация у клиента ее нажимать? Он уже сел в машину и его везут, остальное уже не волнует. Также как и с отзывом после поездки, можно его и оставить, конечно, но можно забить, многие так и делают.
Это вообще ни разу не очевидно для большинства пользователей, что можно сделать второй заказ. Поэтому водитель и просит отменить, понимая, что большинство пользователей отменит.
С определением геолокации клиента возможны те же проблемы, но помимо этого нужно еще обязывать ей делиться (у меня, например, отключено определение геолокации в приложении такси, точку всегда ставлю вручную).
На мой взгляд, у Яндекса не хватает возможности задать при заказе свою цену (выше, чем предлагает сам Яндекс). Нередко бывает, что нужно ехать в какую-то глухомань, где водители не смогут найти другие заказы, поэтому логично они отказываются. Но если обязательно нужно уехать, я готов и за обратную дорогу доплатить, лишь бы довезли.
По сути такая механика есть у Indriver, но в Яндексе ты максимум можешь тариф выбирать и больше ничего.
OVH сейчас не дает купить у них хостинг, если способ оплаты — карта Казахстана. Во всяком случае, после попытки оплатить хостинг такой картой приходит подобное сообщение (пробовал неоднократно):
Order declined Based on an analysis of your order and account data, we believe that these do not provide all the necessary guarantees in terms of transaction security. To process your order, pay for it and execute the contract, OVHcloud invites you to renew your purchase using another payment method. You can also contact one of our advisors via the help section of your account, to provide us with the information needed to complete the transaction. If not, this will not be taken into account.
Там речь про конкретную ситуацию — когда Вася хочет вставить просто текущее время и вызывает функцию now() — но получается не то, что ему хотелось. Вы же как будто говорите про намеренную порчу данных в таблице, а это совсем другой случай.
По-моему, вы что-то путаете. Если вставлять запись с типом timestampz, это означает буквально следующее "в момент вставки было столько-то по UTC". Тут никак не задействованы относительные смещения, просто хранятся моменты по UTC плюс признак "покажи мне эту временную метку по той таймзоне, которая тебе нужна".
Если сервер переезжает в другой часовой пояс, моменты по UTC никуда же не переезжают :) Меняется только дефолтный TimeZone. Условно, раньше поле было 12:10:05 +02:00, стало 14:10:05 +04:00, но это же фактически один и тот же момент времени.
14 лет уже катается, впечатляющий срок. При изначальных 2 годах планируемой длительности эксплуатации.
У следующего аппарата (Perseverance), кстати, проблему с колесами пофиксили, так что есть надежда, что он еще дольше сможет проработать.
Ирония еще в том, что сегодня у индусов главный религиозный праздник, по этой причине у приличной части сотрудников Амазона выходной :)
Смотрите внимательнее. В режиме Read Committed, про который говорится в варианте 2, закоммичены могут быть обе. Об этом говорит официальная дока:
В данном случае вторая транзакция при выполнении
commit();выяснит, что да, произошло параллельное обновление с той же строкой, и попробует заново применить все операции (в данном случае 2 операции UPDATE accounts и операцию SELECT amount). Проблема в том, что проверка на неотрицательность баланса находится в Java-коде, а не в SQL, и СУБД до нее просто не дойдет, успешно закоммитив отрицательный баланс.В вашем варианте 2 (пост-проверка на овердрафт) проблема с отрицательным балансом не решена.
На шаге 3 там сначала выполняется проверка баланса (взятого с шага 2) на неотрицательность, а потом уже коммит транзакции. Но ничего не запрещает параллельной транзакции протиснуться между проверкой баланса и коммитом. Если на счету 100 рублей, а в транзакциях А и Б запрошены переводы на 80 и 70 рублей, то возможна ситуация:
1. проверка перерасхода на шаге 3 в транзакции А
2. проверка перерасхода на шаге 3 в транзакции Б
(Обе проверки пройдут, т.к. ни одно списание не закоммичено и соответственно другие транзакции их не видят)
3. коммит транзакции А
4. коммит транзакции Б
В итоге обе транзакции будут успешны, а проверки перерасхода не сработают. Баланс будет -50 рублей.
Из экипажа Crew-9 уже исключили Кардман и Уилсон, на орбиту полетят только Хейг и Горбунов, чтобы корабль штатно вернулся с МКС с 4 людьми на борту.
Все же с Dragon сравнивать не совсем корректно, он возвращается с низкой околоземной орбиты, а Орион — с Луны почти со второй космической скоростью. А кинетическая энергия капсулы пропорциональна квадрату скорости.
Сравнивать имеет смысл с капсулами Аполлонов скорее.
Да, на восток, конечно, оговорочка вышла :) Но смысл вы правильно поняли
У Байконура хоть и 46 градусов широта, но нельзя с него запускать строго на запад из-за ограничений на поля падения ступеней и головного обтекателя, и траектория чуть отклоняется на север.
Из-за этого наклонение орбиты МКС тоже больше, чем широта Байконура, и составляет 51,6 градуса.
Если стоимость рефакторинга / автоматизации на 1-2 порядка превышает стоимость выполнения X, то автоматизация просто может оказаться нецелесообразной на текущем этапе (например, без понимания востребованности продукта на рынке). Также бывает, что для автоматизации нужны какие-то дополнительные ресурсы / технологии, которых сейчас нет.
Так что в теории все красиво, но на практике рутинные задачи встречаются довольно часто.
А какая мотивация у клиента ее нажимать? Он уже сел в машину и его везут, остальное уже не волнует.
Также как и с отзывом после поездки, можно его и оставить, конечно, но можно забить, многие так и делают.
Это вообще ни разу не очевидно для большинства пользователей, что можно сделать второй заказ. Поэтому водитель и просит отменить, понимая, что большинство пользователей отменит.
А они видят комментарии в тот момент, когда им прилетает уведомление о заказе и они должны его взять или отклонить?
С определением геолокации клиента возможны те же проблемы, но помимо этого нужно еще обязывать ей делиться (у меня, например, отключено определение геолокации в приложении такси, точку всегда ставлю вручную).
На мой взгляд, у Яндекса не хватает возможности задать при заказе свою цену (выше, чем предлагает сам Яндекс).
Нередко бывает, что нужно ехать в какую-то глухомань, где водители не смогут найти другие заказы, поэтому логично они отказываются. Но если обязательно нужно уехать, я готов и за обратную дорогу доплатить, лишь бы довезли.
По сути такая механика есть у Indriver, но в Яндексе ты максимум можешь тариф выбирать и больше ничего.
В большинстве случаев — да (кажется, не видит конечную точку только при рейтинге ниже 4.85)
Геолокация может быть неточной, как понять, действительно ли водитель не доехал до точки или геолокация сбоит?
OVH сейчас не дает купить у них хостинг, если способ оплаты — карта Казахстана.
Во всяком случае, после попытки оплатить хостинг такой картой приходит подобное сообщение (пробовал неоднократно):
Естественно, опечатка, спасибо :)
Там речь про конкретную ситуацию — когда Вася хочет вставить просто текущее время и вызывает функцию
now()— но получается не то, что ему хотелось.Вы же как будто говорите про намеренную порчу данных в таблице, а это совсем другой случай.
По-моему, вы что-то путаете. Если вставлять запись с типом timestampz, это означает буквально следующее "в момент вставки было столько-то по UTC". Тут никак не задействованы относительные смещения, просто хранятся моменты по UTC плюс признак "покажи мне эту временную метку по той таймзоне, которая тебе нужна".
Если сервер переезжает в другой часовой пояс, моменты по UTC никуда же не переезжают :) Меняется только дефолтный TimeZone. Условно, раньше поле было 12:10:05 +02:00, стало 14:10:05 +04:00, но это же фактически один и тот же момент времени.