Транзакционное поведение когда-либо необходимо за пределами баз данных?

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

я реализовал механизм транзакций приложения (в.NET), который отличен от транзакции базы данных. Это на самом деле довольно легко (работа нескольких часов включая комплект модульного теста). Это полностью записано в C# без зависимостей от любой функциональности базы данных или любого другого компонента. Но сначала некоторый контекст...

Эта функция нетранзакции базы данных существует в нескольких проявлениях на платформе Java, такой как с EJBs, ESBs, JMS, и часто в сотрудничестве с BPM. Некоторые из этих проявлений используют базовую базу данных, но не всегда и не из необходимости. Другие платформы имеют сопоставимые проявления, такие как MSMQ.

системы управления версиями самые прежней версии НЕ реализуют семантику транзакции ACID. Как ddaa сказал, CVS не делает, но Подверсия (ее преемник) делает. Визуальный Безопасный Источник не делает. При исследовании Подверсии можно найти сравнительные таблицы, которые считают обязательным для себя это.

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

можно использовать Подверсию неукоснительно, наряду с автоматизированным сценарием сборки (одна команда, которая компилирует, тестирует и упаковывает приложение), и все еще передайте поврежденную сборку репозиторию управления исходным кодом. Я неоднократно видел его. Конечно, это еще легче с non-ACID-transaction-based инструментами управления исходным кодом как VSS. Но для многих людей отвратительно узнать, что это возможно с инструментами как Подверсия.

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

Так, как это возможно? Это возможно, потому что рабочая станция каждого разработчика не является частью транзакции ACID; Подверсия только гарантирует содержание репозитория. Когда Ваш коллега обновил из репозитория, его рабочая станция содержала смешанную копию содержания репозитория (включая Ваши изменения) и его собственные незафиксированные изменения. Когда Ваш коллега работал, чистое основываются на его рабочей станции, он вызывал деловую сделку, которая НЕ была защищена семантикой ACID. Когда он вернулся свои изменения и выполнил обновление, его рабочая станция затем соответствовала репозиторию, но сборка была, все еще повредился. Почему? Поскольку Ваша рабочая станция была также частью отдельной деловой сделки, которая также НЕ была защищена семантикой ACID, в отличие от Вашей фиксации в репозиторий. Так как Вы не обновили свою рабочую станцию для соответствия репозиторию прежде, чем выполнить чистую сборку, Вы на самом деле не создавали исходные файлы, поскольку они существовали в репозитории. При выполнении такого обновления Вы затем нашли бы, что сборка также перестала работать на Вашей рабочей станции.

Теперь я могу рассуждать о своей начальной точке - транзакции имеют объем/контекст, который нужно рассмотреть тщательно. Просто, потому что у Вас есть транзакция ACID, не означает, что Ваша бизнес-логика безопасна, ЕСЛИ объем/контекст транзакции ACID и бизнес-логики не соответствует ТОЧНО. Если Вы полагаетесь на некоторую форму транзакции базы данных ACID, но Вы делаете ЧТО-ЛИБО в своей бизнес-логике, которая не покрыта той транзакцией базы данных, то у Вас есть разрыв, который может позволить сопоставимую и катастрофическую ошибку. Если можно вынудить бизнес-логику точно соответствовать транзакции базы данных, то все хорошо. В противном случае затем Вам, вероятно, нужна отдельная деловая сделка. В зависимости от природы незащищенной логики Вы, возможно, должны реализовать свой собственный механизм транзакций.

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

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

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