Всеосяжна підтримка транзакцій є однією з найбільш вагомих причин використання Spring Framework. Spring Framework надає узгоджену абстракцію для керування транзакціями, яка забезпечує наступні переваги:

  • Узгоджена модель програмування для різних API-інтерфейсів транзакцій, таких як Java Transaction API (JTA), JDBC, Hibernate та Java Persistence API (JPA).

  • Підтримка декларативного управління транзакціями.

  • Спрощений API-інтерфейс для програмного управління транзакціями замість складних API-інтерфейсів транзакцій, таких як JTA.

  • Чудова інтеграція з абстракціями доступу до даних із Spring.

Переваги моделі підтримки транзакцій Spring Framework

Традиційно розробники Java EE мали два варіанти управління транзакціями: через глобальні або локальні транзакції, причому обидва з цих двох варіантів мають серйозні обмеження. Глобальне та локальне управління транзакціями розглянуто у наступних двох розділах, після чого йде опис того, яким чином засоби підтримки управління транзакціями у Spring Framework усувають обмеження глобальної та локальної моделей транзакцій.

Глобальні транзакції

Глобальні транзакції дозволяють працювати з кількома транзакційними ресурсами, зазвичай реляційними базами даних та чергами повідомлень. Сервер додатків керує глобальними транзакціями через JTA, який є громіздким API-інтерфейсом (частково через модель винятків). Крім того, UserTransaction з JTA зазвичай необхідно отримувати з JNDI, а це означає, що також доводиться використовувати JNDI, щоб застосувати JTA. Використання глобальних транзакцій обмежує будь-яке потенційне повторне використання коду програми, оскільки JTA зазвичай доступний лише в середовищі сервера додатків.

Java-університет

Раніше кращим способом використання глобальних транзакцій був метод з використанням транзакцій EJB, що управляються контейнером (Container Managed Transaction/CMT). CMT є формою декларативного управління транзакціями (на відміну програмного управління транзакціями). CMT з EJB усуває необхідність у зв'язаному з транзакціями пошуку через JNDI, хоча використання самого EJB вимагає використання JNDI. Це дозволяє здебільшого позбутися, хоч і не повністю, необхідності писати Java-код для управління транзакціями. Істотним недоліком є те, що CMT прив'язаний до JTA та оточення сервера додатків. До того ж, він доступний лише в тому випадку, якщо ти вирішиш реалізувати бізнес-логіку в класах EJB (або принаймні в межах транзакційного фасаду EJB). Недоліки EJB загалом такі значні, що його використання перестає бути привабливим, особливо порівняно з адекватними альтернативами для декларативного управління транзакціями.

Локальні транзакції

Локальні транзакції залежать від ресурсу, наприклад, у випадку транзакції, пов'язаної з підключенням JDBC. Локальні транзакції можуть бути простішими у використанні, але мають істотний недолік: вони не можуть працювати з кількома транзакційними ресурсами. Наприклад, код, який управляє транзакціями за допомогою підключення JDBC, не може виконуватись у глобальній транзакції JTA. Оскільки сервер програм не бере участі в управлінні транзакціями, він не може забезпечити коректність роботи з кількома ресурсами. (Варто зазначити, що більшість додатків використовують один ресурс транзакції.) Іншим недоліком є те, що локальні транзакції діють агресивно щодо моделі програмування.

Модель узгодженого програмування у Spring Framework

Spring усуває недоліки глобальних та локальних транзакцій. Це дозволяє розробникам додатків використовувати модель узгодженого програмування у будь-якому оточенні. Ти пишеш свій код один раз, а він, у свою чергу, може користуватися різними стратегіями управління транзакціями в різних оточеннях. Spring Framework забезпечує як декларативне, і програмне управління транзакціями. Більшість користувачів надають перевагу декларативному управлінню транзакціями, яке ми і рекомендуємо в більшості випадків.

У разі з програмним управлінням транзакціями розробники мають справу з абстракцією транзакцій Spring Framework, яка може працювати у будь-якій базовій інфраструктурі транзакцій. При використанні кращої декларативної моделі розробники зазвичай пишуть невеликий об'єм або взагалі не пишуть код, пов'язаний з керуванням транзакціями, а отже, не залежать від API-інтерфейсу транзакцій зі Spring Framework або будь-якого іншого API-інтерфейсу транзакцій.

Чи потрібен сервер додатків для керування транзакціями?

Підтримка керування транзакціями Spring Framework змінює традиційні правила щодо обов'язкової наявності сервера додатків для Java-додатків.

Якщо мова йде виключно про декларативні транзакції через класи EJB, сервер додатків не потрібний. Фактично, навіть якщо твій сервер додатків має повнофункціональні засоби JTA, ти все одно можеш замислитися про те, що декларативні транзакції Spring Framework забезпечують більший функціонал і більш продуктивну модель програмування, ніж CMT з EJB.

Як правило, можливості JTA сервера додатків потрібні лише в тому випадку, якщо програмі необхідно обробляти транзакції за кількома ресурсами, що не є обов'язковою вимогою для багатьох додатків. Багато програм вищого класу замість цього використовують єдину базу даних, що добре масштабується (наприклад, Oracle RAC). Автономні диспетчери транзакцій (такі як Atomikos Transactions та JOTM) є ще одним варіантом. Звісно, можуть знадобитися інші засоби сервера програм, такі як Служба повідомлень Java (Java Message Service/JMS) та Архітектура конекторів Java EE (Java EE Connector Architecture/JCA).

Платформа Spring Framework дозволяє обрати час масштабування до повністю завантаженого сервера додатків. Минули часи, коли єдиною альтернативою використанню CMT з EJB або JTA було написання коду з локальними транзакціями (наприклад, у з'єднаннях JDBC) і виникала необхідність значного переписування коду, якщо потрібно, щоб цей код виконувався в межах глобальних транзакцій, керованих контейнером. У Spring Framework необхідно змінити лише деякі визначення бінів у конфігураційному файлі (а не код).