Где лежит ответственность за обеспечение ACID-свойств транзакции?

Question

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

** Мой вопрос касается именно фразы.

гарантируется транзакциями

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

Давайте пройдемся по каждому свойству: -

1. Атомность: - Предположим, что когда мы создаем клиента, учетная запись также должна быть создана, поскольку она является обязательной. Так что теперь во время транзакции клиент создается во время создания учетной записи. Таким образом, разработчик теперь может пойти двумя путями: либо он откатывает завершить транзакцию (в этом случае соблюдается атомарность), или он фиксирует транзакцию, поэтому клиент будет создан, но не аккаунт (что нарушает атомарность). Так ответственность лежит на разработчике?

2. Согласованность: - та же причина действительна и для согласованности

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

4. Долговечность: - Если мы фиксируем транзакцию, то даже в случае сбоя приложения оно должно быть зафиксировано при перезапуске приложения. Не уверены, что это нужно позаботиться разработчику или поставщику базы данных / транзакции?

Так что, насколько я понимаю, эти свойства ACID не гарантируются автоматически; скорее мы, как разработчик, должны их достичь. пожалуйста, дайте мне знать если выше понимание относительно каждого пункта является правильным? Буду признателен, если вы, ребята, можете ответить за каждое очко (да / нет, также подойдет.

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

Answer 1

1. Транзакции базы данных являются атомарными: они либо происходят полностью, либо не происходят вообще.Само по себе это ничего не говорит об атомарности бизнес-транзакций .Существуют различные стратегии для сопоставления бизнес-транзакций с транзакциями базы данных.В простейшем случае бизнес-транзакция реализуется одной транзакцией базы данных (где бизнес-транзакция прерывается путем отката базы данных).Тогда атомарность транзакций базы данных подразумевает атомарность бизнес-транзакций.Однако все становится сложнее, когда бизнес-операции охватывают несколько транзакций базы данных ...
2. См. Выше.
3. Ваше утверждение верно.Часто более слабые гарантии достаточны для подтверждения правильности.

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

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

   неверно.Если транзакция совершена, больше ничего не остается.

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

Answer 2

Транзакции гарантируют ACID более или менее:

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

2) Согласованность.Гарантировано атомарностью.

3) Изоляция.Вы должны определить уровень изоляции, в котором нуждается ваше приложение.Значение по умолчанию определяется в зависимости от базы данных, контейнера ... Наиболее распространенным является READ COMMITTED.Будьте осторожны с замками, так как это может привести к зависанию в зависимости от вашей логики и уровня изоляции.

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

В общем, вам следуетзнать о транзакциях и настраивать их в контейнере объявления по коду «звезда» и «конец» (commit, rollback).