Транзакции JMS и платформа SOA. (перевод, часть 1)

Оригинал статьи - "JMS Transactions and the SOA Platform".

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

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

Транзакции и ACID-свойства

Что же такое "транзакция"? К сожалению, этим словом зачастую злоупотребляют в софтверной отрасли, как и многими другими. На самом деле транзакция представляет собой логическое объединение нескольких отдельных действий - в одно большое действие, при этом большое действие или выполняется, или не выполняется, по принципу - "все-или-ничего", оно расценивается как оценка выполнения совокупности всех отдельных действий, входящих в нее [1].

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

Транзакции часто описывают в терминах "ACID"[2]-свойств:

• Атомарность. Когда мы говорим об "атомарности" транзакции, мы имеем в виду, что транзакция, состоящая из нескольких отдельных действий - может рассматриваться только как одно атомарное целое. Если любое одно из этих отдельных действий не удается, как в нашем примере любая операция с одним из денежных счетов, то все будет отменено. (Термин, используемый для описания этого - "Откат транзакции" - "Roll back"). Транзакция - это конструкция "все-или-ничего". Транзакцию можно завершить (сделать "Commit" для фиксации транзакции), только при условии, что все отдельные действия, входящие в нее - завершились успешно.
• Согласованность. Транзакция не может оставлять данные, которыми она оперирует, в неком несогласованном, промежуточном состоянии. Если транзакция откатывается, то и оперируемые ею данные должны вернуться в начальное состояние, которое у них было до момента начала транзакции.
• Изолированность. В контексте транзакции ее изолированность означает, что любые данные из промежуточного состояния транзакции будут не видны, не доступны - для другой транзакции. Например если наш банковский перевод выполняется как одна транзакция, то пока она не будет завершена - другие процессы не смогут увидеть данные по каждой из совокупных операций, входящих в транзакцию.
• Долговечность. При фиксации успешной транзакции данные должны быть должным образом сохранены, никакой аппаратный или любой другой сбой не должен вызвать потерю уже сохраненных данных. Тоже самое должно быть обеспечено при откате транзакции - данные должны быть так же надежно сохранены.

(см. продолжение)