управление транзакциями с помощью компонентов Common-J - PullRequest
Новая
       13

управление транзакциями с помощью компонентов Common-J

0 голосов
/ 20 апреля 2009

У нас есть приложение Websphere Java EE, требующее распараллеливания, для которого мы хотим использовать рабочие компоненты CommonJ .

Каждый «поток» требует своего собственного представления данных, поступающих из базы данных. Большая часть этого была бы предварительно извлечена, но все равно нужно было бы пойти в базу данных, чтобы получить некоторые. Мы ожидаем, что продолжительность общей работы всех этих потоков будет «большой» (т. Е. Достаточно времени для изменения базовых данных).

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

Кажется, что единственный способ убедиться в этом - это иметь «глобальную» транзакцию и использовать транзакции XA. Но мы хотели бы избежать этой сложности (и накладных расходов), если это вообще возможно, и ищем идеи или альтернативы: есть мысли?

Кроме того, в какой степени (если вообще) рабочие компоненты Common-J поддерживают транзакции, управляемые контейнером?

@ Карл: Возможно, я просто имел в виду накладные расходы. Мы думали, что транзакции XA и обмен сообщениями несут накладные расходы, которых могут избежать рабочие компоненты Common-J, совместно использующие транзакцию? Используемый набор данных будет иметь> 300 тыс. Отдельных строк данных, для каждой из которых потребуется ~ 100 вычислений. В то время как они могут быть разделены на разные потоки, работающие с общими, кэшированными, доступными только для чтения данными, сравнительные накладные расходы памяти на копирование в / чтение из очереди кажутся непомерно высокими. Вы бы согласились?

@ Карл: от десятков до сотен миллисекунд на единицу. Мы также сосредоточены на улучшении логической обработки в качестве отдельной задачи.
Нужно ли использовать транзакции XA, когда требуется, чтобы все потоки имели согласованное представление данных в одной базе данных? Мой ответ на этот вопрос заключается в том, что каждому потоку потребуется собственный JPA EntityManager (например, соединение), и для координации их доступа потребуется XA.
Но если я могу сделать это без XA, то тем лучше, нет?

1 Ответ

1 голос
/ 22 апреля 2009

Что вы находите сложным в транзакции XA в WAS? Судя по всему, XA-транзакция выглядит хорошо, если вы беспокоитесь о целостности данных.

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

Karl

...