Я должен с уважением не согласиться: транзакционные системы не являются автоматическими и исключительно движками баз данных, скорее наоборот ...
Я реализовал механизм транзакций приложения (в .NET), который отличается от транзакции базы данных. На самом деле это довольно просто (несколько часов работы, включая тестовый набор). Он полностью написан на C # без каких-либо зависимостей от какой-либо функциональности базы данных или любого другого компонента. Но сначала немного контекста ...
Эта функция без транзакций базы данных существует в нескольких проявлениях на платформе Java, например, с EJB, ESB, JMS, и часто в связи с BPM. Некоторые из этих проявлений используют базовую базу данных, но не всегда и не по необходимости. Другие платформы имеют сопоставимые проявления, такие как MSMQ.
Большинство устаревших систем контроля версий НЕ реализуют семантику транзакций ACID. Как сказал ddaa, CVS не делает, а делает Subversion (его преемник). Visual Source Safe этого не делает. Если вы исследуете Subversion, вы можете найти сравнительные таблицы, которые подтверждают это.
Теперь для критической точки транзакция базы данных или ее эквивалент не гарантирует безопасную бизнес-логику. Хотя я люблю Subversion, по иронии судьбы это прекрасный пример этого факта.
Вы можете использовать Subversion неукоснительно, вместе со сценарием автоматической сборки (одна команда, которая компилирует, тестирует и упаковывает ваше приложение), и по-прежнему фиксировать поврежденную сборку в репозитории контроля версий. Я видел это неоднократно. Конечно, это еще проще с инструментами управления источниками, не основанными на ACID-транзакциях, такими как VSS. Но многие шокированы, узнав, что это возможно с помощью таких инструментов, как Subversion.
Разрешите, пожалуйста, изложить сценарий. Вы и коллега разрабатываете приложение и используете Subversion для репозитория исходного кода. Вы оба пишете код и время от времени добавляете в хранилище. Вы вносите несколько изменений, запускаете чистую сборку (перекомпилируете все исходные файлы) и все тесты проходят. Итак, вы делаете свои изменения и идете домой. Ваш коллега работает над своими собственными изменениями, поэтому он также запускает чистую сборку, видит все тесты пройденными и фиксирует их в хранилище. Но ваш коллега затем обновляется из репозитория, делает еще несколько изменений, запускает чистую сборку, и сборка взрывается ему в лицо! Он отменяет свои изменения, обновления из хранилища снова (просто чтобы быть уверенным), и обнаруживает, что чистая сборка все еще взрывается! Ваш коллега проводит следующие пару часов, устраняя неполадки в сборке и источнике, и в конечном итоге находит изменения, которые вы внесли перед уходом, что приводит к сбою сборки. Он отправляет вам и вашему боссу неприятное электронное письмо с жалобой на то, что вы сломали сборку, а затем небрежно пошли домой. Вы прибываете утром, чтобы найти вашего коллегу и вашего начальника, ожидающих вас за столом, а все остальные наблюдают за вами! Таким образом, вы быстро запускаете чистую сборку и показываете, что сборка не сломана (все тесты проходят, как и прошлой ночью).
Итак, как это возможно? Это возможно, потому что каждая рабочая станция разработчика не является частью транзакции ACID; Subversion гарантирует только содержимое хранилища. Когда ваш коллега обновился из хранилища, его рабочая станция содержала смешанную копию содержимого хранилища (включая ваши изменения) и его собственные незафиксированные изменения. Когда ваш коллега выполнил чистую сборку на своей рабочей станции, он вызывал бизнес-транзакцию, которая НЕ была защищена семантикой ACID. Когда он отменил свои изменения и выполнил обновление, его рабочая станция соответствовала хранилищу, но сборка все еще была повреждена. Зачем? Потому что ваша рабочая станция была также частью отдельной бизнес-транзакции, которая также НЕ была защищена семантикой ACID, в отличие от вашей фиксации в хранилище. Поскольку вы не обновляли свою рабочую станцию до соответствия хранилищу перед запуском чистой сборки, вы на самом деле не собирали исходные файлы, как они существовали в хранилище. Если вы произвели такое обновление, вы обнаружите, что сборка также не удалась на вашей рабочей станции.
Теперь я могу изложить свою исходную точку - транзакции имеют контекст / контекст, который необходимо тщательно продумать. Тот факт, что у вас есть транзакция ACID, не означает, что ваша бизнес-логика безопасна, НЕ РАЗРЕШАЕТСЯ объем / контекст транзакции ACID, и бизнес-логика точно соответствует. Если вы полагаетесь на какую-либо форму транзакции ACID базы данных, но вы делаете НИЧЕГО в своей бизнес-логике, которая не покрывается этой транзакцией базы данных, то у вас есть пробел, который может допустить сопоставимую и катастрофическую ошибку. Если вы можете заставить свою бизнес-логику точно соответствовать транзакции базы данных, то все в порядке. Если нет, то вам, вероятно, нужна отдельная бизнес-операция. В зависимости от характера незащищенной логики вам может потребоваться реализовать собственный механизм транзакций.
Итак, обмен сообщениями может быть транзакционным, но область действия - это просто сообщение. Что касается приведенного выше примера, контекст Subversion - это только отдельная фиксация в хранилище. Однако бизнес-транзакция представляет собой чистую сборку, которая включает в себя гораздо больший объем. Эта конкретная проблема обычно решается с помощью сценариев чистой сборки вместе с чистой проверкой, в идеале с использованием реализации непрерывной интеграции (например, через CruiseControl или тому подобное). На рабочих станциях разработчиков требуется, чтобы каждый разработчик применял дисциплину для выполнения полного обновления (или даже чистой проверки) перед чистой сборкой.
Итак, скажем, каждая транзакция имеет область действия или контекст, который ограничивает ее защиту. Бизнес-транзакции часто включают логику, которая выходит за рамки механизмов транзакций (таких как ядро базы данных), которые мы обычно используем. Возможно, вам придется восполнить разницу. В редких случаях для этого может даже иметь смысл написать собственный механизм транзакций.
Я спроектировал переписывание критической бизнес-системы для скромной компании из девяноста человек. Я счел необходимым внедрить такой механизм, и я обнаружил, что этот опыт прост, полезен и полезен. Я бы сделал это снова, возможно, немного легче, но я всегда задавался вопросом, почему я не мог придерживаться только транзакции базы данных.