управление транзакциями с компонентами common-j

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

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

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

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

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

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

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


multithreading transactions parallel-processing websphere jakarta-ee
person Edward Q. Bridges    schedule 20.04.2009    source источник
comment
Я думаю, вы будете удивлены тем, насколько низки накладные расходы на XA и обмен сообщениями в WAS. Похоже, меня больше беспокоит логика своевременной обработки данных. Какие временные рамки приемлемы для вас и сколько времени, по вашему мнению, займет обработка 1 объекта? Вы также можете кластеризовать WAS, что очень просто. Карл   -  person Karl    schedule 23.04.2009

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Карл

person Karl    schedule 22.04.2009