2014-12-17 4 views
2

В документации App Engine (https://cloud.google.com/appengine/docs/python/ndb/transactions) говорится: «Если транзакция« сталкивается »с другой, она терпит неудачу: NDB автоматически повторяет такие неудачные транзакции несколько раз».Операционная система транзакций NDB App Engine

Смысл этого предложения не совсем ясен для меня. Если сначала начинается транзакция A, а затем транзакция B начинается в середине операции A, означает ли это, что и A, и B сбой и повторная попытка? Или происходит только B, а A продолжается?

Также есть связанный с этим вопрос: существуют ли случаи, когда транзакция будет частично завершена, а затем откат? Или каждая попытка транзакции вообще не входит в функцию до тех пор, пока у нее не будет возможности выполнить эту функцию?

Спасибо!

ответ

2

Скорее всего, одна из транзакций будет успешной, а другая потерпит неудачу (и будет перепробована), но вы не можете заранее сказать, какой из них; это is также возможно, что оба могут потерпеть неудачу (и будут отдельно перепробованы).

И да, fail В общем, означает partly progresses but then gets rolled back. Это «оптимистичный параллелизм», а не один, основанный на упреждающем locking.

Помните, что потенциально конфликтующие транзакции, как правило, запрашиваются на многих распределенных машинах, координируя их чем угодно, но «оптимистичный параллелизм» (обнаружение конфликтов и откатывание тех, которые не могут завершиться чисто) было бы неосуществимым.

+0

Благодарим за ответ! Из того, что вы написали, похоже, что оптимистический контроль параллелизма не гарантирует, что ЛЮБОЙ из нескольких параллельных запросов будет завершен без прерывания, в отличие от системы блокировки (где запросы будут выполняться последовательно, гарантируя базовый уровень производительности). Учитывая это, я не совсем понимаю ваше последнее предложение; кажется, что в системе с множеством параллельных запросов пессимистическая система управления будет превосходить оптимистичную. Не могли бы вы указать на ошибку в моих рассуждениях? Благодаря! – Site

+1

В распределенной системе с множеством «столкновений» * одновременных запросов производительность будет ужасной в любом случае - либо из-за многих попыток, либо из-за огромных накладных расходов при создании распределенных блокировок. Поэтому рекомендуется использовать * shard * счетчики на https://cloud.google.com/appengine/articles/sharding_counters. Но в системе с блокировкой вы платите ту же чрезвычайно высокую цену, даже если для нее нужна нумерация - транзакции не будут конфликтовать - в оптимистичном случае вы платите редко, когда это необходимо. Аналогии: экспоненциальное отключение TCP; Ethernet-триумф над Token Ring :-). –

Смежные вопросы