Оптимистическая и пессимистическая блокировка

Вероятнее всего, ваша проблема связана с этим

Безопасность подключения: STARTTLS Connection Security: SSL / TLS

Это два разных протокола: используете ли вы правильный, независимо от того, re использование в Thunderbird должно быть использовано.

Попробуйте установить переменную:

// if you're using SSL
$mail->SMTPSecure = 'ssl';
// OR use TLS
$mail->SMTPSecure = 'tls';
468
задан Hearen 5 May 2019 в 11:27
поделиться

6 ответов

Оптимистическая Блокировка является стратегией, где Вы читаете запись, принимаете во внимание номер версии (другие методы, чтобы сделать, это включает даты, метки времени или контрольные суммы/хеши), и проверьте, что версия не изменилась перед обратной записью записи. Когда Вы пишете запись назад, Вы фильтруете обновление на версии, чтобы удостовериться, что это является атомарным. (т.е. не был обновлен между тем, когда Вы проверяете версию и пишете запись на диск), и обновите версию в одном хите.

, Если запись грязна (т.е. различная версия к Вашему) Вы прерываете транзакцию, и пользователь может перезапустить его.

Эта стратегия является самой применимой к системам большого объема и трехуровневой архитектуре, где Вы не обязательно поддерживаете соединение с базой данных для Вашей сессии. В этой ситуации клиент не может на самом деле поддержать блокировки базы данных, поскольку соединения взяты от пула, и Вы не можете использовать то же соединение от одного доступа до следующего.

Пессимистическая Блокировка состоит в том при блокировке записи для эксклюзивного использования, пока Вы не закончили с ним. Это имеет намного лучшую целостность, чем оптимистическая блокировка, но требует, чтобы Вы были осторожны с Вашим проектированием приложений для предотвращения Мертвые блокировки . Для использования пессимистической блокировки, Вам нужен любой прямое подключение к базе данных (как обычно имел бы место в два клиент-сервера уровня приложение), или внешне доступный идентификатор транзакции, который может использоваться независимо от соединения.

В последнем случае Вы открываете транзакцию с TxID и затем повторно подключаете использование тот идентификатор. DBMS поддерживает блокировки и позволяет Вам брать сессию назад через TxID. Это - то, как работают распределенные транзакции с помощью двухфазных протоколов подтверждения изменений (такой как XA или Транзакции COM + ).

689
ответ дан nc. 5 May 2019 в 11:27
поделиться

Оптимистическая блокировка используется, когда Вы не ожидаете много коллизий. Это стоит меньше, чтобы сделать нормальное функционирование, но если бы коллизия ДЕЙСТВИТЕЛЬНО происходит, Вы заплатили бы более высокую цену для разрешения его, поскольку транзакция прерывается.

Пессимистическая блокировка используется, когда коллизия ожидается. Транзакции, которые нарушили бы синхронизацию, просто заблокированы.

Для выбора надлежащего механизма блокировки необходимо оценить объем чтений и записей и плана соответственно.

147
ответ дан Hearen 5 May 2019 в 11:27
поделиться

В дополнение к тому, что уже было сказано, нужно сказать, что оптимистическая блокировка имеет тенденцию улучшать параллелизм за счет предсказуемости. Пессимистическая блокировка имеет тенденцию уменьшать параллелизм, но более предсказуема.

Вы платите свои деньги, и т.д.

40
ответ дан Peter Perháč 5 May 2019 в 11:27
поделиться

Оптимистичный предполагает, что ничто не собирается измениться при чтении его.

Пессимистичный предполагает, что что-то будет и так блокировать его.

, Если не важно, чтобы данные были отлично считаны оптимистичное использование. Вы могли бы получить нечетное 'грязное' чтение - но оно, намного менее вероятно, приведет к мертвым блокировкам и т.п..

Большинство веб-приложений соглашается с грязными чтениями - в редком случае, данные точно не соответствуют следующей перезагрузке, делает.

Для точных операций данных (как во многих финансовых транзакциях) пессимистичное использование. Важно, чтобы данные были точно считаны без непоказанных изменений - дополнительная блокировка наверху стоит того.

, О, и значения по умолчанию Microsoft SQL server к фиксации страницы - в основном строка Вы читаете и некоторые любая сторона. Блокировка строки более точна, но намного медленнее. Часто стоит установить Ваши транзакции на фиксировавший чтению или без блокировок для предотвращения мертвых блокировок при чтении.

64
ответ дан Keith 5 May 2019 в 11:27
поделиться

Партия хороших вещей была сказана выше об оптимистической и пессимистической блокировке. Один важный момент для рассмотрения следующие:

При использовании оптимистической блокировки, нам нужно к осторожному из того, это, как приложение восстановится с этих отказов.

Особенно в асинхронном сообщении управляемая архитектура, это может вести неисправной обработки сообщения или потерянных обновлений.

сценарии Отказов должны быть продуманы.

1
ответ дан 22 November 2019 в 22:33
поделиться

При контакте с конфликтами у Вас есть две опции:

  • можно стараться избегать конфликта, и это - то, что делает Пессимистическая Блокировка.
  • Или, Вы могли позволить конфликту происходить, но необходимо обнаружить его после фиксации транзакций, и это - то, что делает Оптимистическая Блокировка.

Теперь, давайте рассмотрим следующий Потерянная аномалия Обновления :

Lost Update

Потерянная аномалия Обновления может произойти в Read, Фиксировавший уровень изоляции.

В схеме выше мы видим, что Alice полагает, что может уйти 40 от нее account, но не понимает, что Bob только что изменил остаток на счете, и теперь существуют только 20 оставленные в этой учетной записи.

Пессимистическая Блокировка

Пессимистическая блокировка достигает этой цели путем взятия общей блокировки, или чтение соединяют учетную запись, таким образом, Bob препятствуют изменить учетную запись.

Lost Update Pessimistic Locking

В схеме выше, и Alice и Bob получат чтение, соединяются account строка таблицы, которую считали оба пользователя. База данных получает, они соединяют SQL Server при использовании Повторяемого Read или сериализуемый.

, поскольку и Alice и Bob читали account со значением PK 1, ни один из них не может изменить его до разъединений абонентом блокировка чтения. Это вызвано тем, что операция записи требует приобретения записи/монопольной блокировки и совместно использовала/читала блокировки, предотвращают запись/монопольные блокировки.

Только после того, как Alice фиксировала свою транзакцию, и блокировка чтения была выпущена на account строка, Bob UPDATE возобновит и применит изменение. Пока Alice не выпускает блокировку чтения, блоки ОБНОВЛЕНИЯ Bob's.

для получения дополнительной информации о том, как платформы доступа к данным используют базовую базу данных пессимистическая поддержка блокировки, проверьте эта статья .

Оптимистическая Блокировка

, Оптимистическая Блокировка позволяет конфликту происходить, но обнаруживает его после применения ОБНОВЛЕНИЯ Alice, поскольку версия изменилась.

Application-level transactions

На этот раз, у нас есть еще version столбец. version столбец увеличен каждый раз ОБНОВЛЕНИЕ, или УДАЛИТЕ, выполняется, и он также используется в операторе Where ОБНОВЛЕНИЯ и Операторов удаления. Чтобы это работало, мы должны выпустить ВЫБОР и считать ток version до выполнения ОБНОВЛЕНИЯ или УДАЛИТЬ, как иначе, мы не знали бы что значение версии передать оператору Where или увеличить.

для получения дополнительной информации о том, как платформы доступа к данным реализуют оптимистическую блокировку, проверьте этот Прикладной уровень статьи .

транзакции

, Системы реляционных баз данных появились в конце 70-х в начале 80-х, когда клиент, обычно, соединялся бы с мейнфреймом через терминал. Вот почему мы все еще видим, что системы баз данных определяют условия, такие как установка SESSION.

В наше время, по Интернету, мы больше не выполняем чтения и записи в контексте той же транзакции базы данных, и ACID больше не достаточен.

, Например, рассмотрите следующий вариант использования:

enter image description here

Без оптимистической блокировки, нет никакого способа, которым это Потерянное Обновление было бы поймано даже если транзакции базы данных, используемые сериализуемый. Это вызвано тем, что чтения и записи выполняются в отдельных Запросах HTTP, следовательно на различных транзакциях базы данных.

Так, оптимистическая блокировка может помочь Вам предотвратить Потерянные Обновления даже когда с помощью транзакций прикладного уровня, которые соединяются, пользователь - думают время также.

для получения дополнительной информации о прикладном уровне или логических транзакциях, проверьте это Заключение

статьи .

, Оптимистическая блокировка является очень полезной техникой, и это работает просто великолепно даже когда с помощью менее - строгие уровни изоляции, как Зафиксированный Read, или когда чтения и записи выполняются в последующих транзакциях базы данных.

оборотная сторона оптимистической блокировки - то, что откат будет инициирован по условию платформа доступа после ловли OptimisticLockException, поэтому теряя всю работу, которую мы сделали ранее в настоящее время выполняющейся транзакцией.

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

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

6
ответ дан 22 November 2019 в 22:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: