Java EE / EJB против Spring для управления распределенными транзакциями с несколькими кластерами БД - PullRequest
4 голосов
/ 25 января 2012

У меня есть требование для создания прототипа (работающего на сервере приложений, совместимого с J2EE с MySQL), демонстрирующего следующее

  • Продемонстрировать способность распределять транзакции по нескольким базам данных, расположенным на разных сайтах по всему миру (репликация данных, управляемая приложением)

  • Продемонстрировать способность записывать транзакции в базу данных из нескольких кластеров базы данных, расположенных в нескольких местах. Выбор базы данных для записи зависит от местоположения пользователя. (База данных управляет репликацией данных)

У меня есть возможность выбрать либо стек Spring, либо стек Java EE (EJB и т. Д.). Было бы полезно узнать ваше мнение о том, какой стек лучше поддерживать распределенные транзакции в нескольких кластерах базы данных.

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

Я видел много сайтов при поиске в Google, но большинство из них устарели (т.е. до EJB 3 и до Spring 3)

Спасибо

1 Ответ

1 голос
/ 27 января 2012

Я бы использовал стек JavaEE следующим образом:

  • настроить XA DataSource для каждого сервера базы данных
  • в зависимости от местоположения пользователя, EJB без сохранения состояния ищет соответствующий источник данных и получает от него соединение
  • при трансляции транзакции на все серверы Stateless EJB должен выполнить итерацию по всем сконфигурированным источникам данных, чтобы выполнить один или несколько запросов к ним, но в одной транзакции

В случае технического сбоя транзакция откатывается на всех соответствующих серверах. В случае сбоя в работе кода код может вызвать откат благодаря context.setRollbackOnly().

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

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

...