Транзакция EJB против транзакции Oracle

Question

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

Как это работает с транзакциями?Есть ли риск, что у меня есть два отдельных сервера, поэтому два отдельных репозитория транзакций EJB и только одна база данных, поэтому одно «хранилище» транзакций базы данных?архитектура недействительна, и что есть лучшие способы, но об этой транзакции EJB против Oracle, где я стою?

Спасибо.

Answer 1

JTA использует противоположный сценарий, я имею в виду, когда из 1 контекста EJB вы взаимодействуете с несколькими транзакционными ресурсами (например, 2 разными базами данных, или JMS-серверами, или другими).Это не твой случай.JTA позаботится о том, чтобы инициировать 1 транзакцию в каждом из этих ресурсов при запуске транзакции EJB и фиксировать во всех из них (или откатывать все из них в случае сбоя) вместе с транзакцией EJB.

В вашем случаевы можете использовать JTA или нет, потому что у вас есть только 1 транзакционный ресурс.

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

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

Надеюсь, это поможет.

Answer 2

Вы не говорите, если у вас есть EJB на одном сервере, который делает удаленные вызовы другим EJB на втором сервере.

Если мы предполагаем, что вы просто собираетесь развернуть свое приложение на кластерном сервере приложений с двумяузлы, то XA (двухфазная фиксация) не имеет значения, потому что вы можете заставить свое приложение использовать локальные EJB-компоненты, что означает, что вся связь между EJB-компонентами остается на одном узле.

Вам необходимо вставить балансировщик нагрузки напротивдва узла, и он может распределить нагрузку между двумя узлами.

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

Простая архитектура, подобная этой, вполне нормальна, и вы найдете тысячи приложений по всему миру, созданных подобным образом.

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

Единственная проблема этой архитектуры - вопрос о том, что происходиткогда узел «исчезает», скажем, из-за сбоя или если его отключили, например, из-за обслуживания оборудования.В этом случае веб-сеанс пользователя будет потерян, если вы не попросите сервер приложений обмениваться сеансами между узлами.Если вы сделаете это, общая производительность пострадает из-за постоянного совместного использования состояния сеанса между узлами.В качестве альтернативы, если эта функция не активирована, у вас есть проблема с тем, что последовательные веб-запросы должны перенаправляться на один и тот же узел с помощью балансировщика нагрузки.

Вы будете лучше знать свои требования и должны будете точно выбрать, какая архитектураВы выбираете.

Answer 3

Способ работает через JTA.

JTA поддерживает распределенные транзакции и управление ими. Чтобы позволить базе данных участвовать в распределенной транзакции, вы должны использовать ресурсы XA (осведомленные о транзакции).

Вот статья о EJB3 и транзакциях. Немного устаревший, но он касается деталей

http://java.sys -con.com / узел / 325149

Как и все остальное, использование JTA и XA сопряжено с рисками и выгодами. Вам гарантирована целостность данных, и если ваше приложение в значительной степени полагается на транзакционность, то это может быть целесообразным подходом. Недостатком этого является то, что XA менее эффективен, и всегда существует риск того, что какое-то приложение dosnwstream может в конечном итоге удерживать блокировку базы данных в течение очень долгого времени.