Распространение транзакций Oracle между C ++ и Java

Question

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

Теперь мой менеджер считает, что нам понадобятся стороны Java и C ++ для участия в одной и той же транзакции БД Oracle. Это связано, но отличается от обычной проблемы распределенных транзакций с наличием одного процесса, координирующего 2 транзакционных ресурса, таких как БД и очередь сообщений.

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

Я знаком с транзакциями XA и провел некоторую работу с JBoss Transaction Manager, но мой поиск не дал ничего хорошего при распространении транзакции XA между двумя процессами.

Мы используем Spring на стороне Java, и в их документации прямо говорится, что они не предоставляют никакой помощи в распространении транзакций.

Мы не планируем использовать традиционный сервер Java EE (например, IBM Websphere), который может иметь поддержку для распространения (не то, чтобы я мог найти какую-либо окончательную документацию).

Любая помощь или указатели на решения очень приветствуются.

Answer 1

В блоге Лорана Шнайдера есть пример *1002* использования пакета DBMS_XA внутри Oracle, чтобы разрешить нескольким сеансам работать в одной транзакции. Таким образом, было бы возможно, чтобы сеансы Java и C ++ участвовали в одной транзакции без необходимости какого-либо дополнительного координатора.

Кроме того, вы можете рассмотреть возможность использования Workspace Manager. Первоначально он был разработан для поддержки чрезвычайно длительных транзакций (т. Е. Манипулирования большим количеством пространственных данных для предлагаемой разработки). По сути, вы можете создать рабочее пространство, которое в вашем случае будет примерно эквивалентно именованной транзакции. Код Java и C ++ может входить в это рабочее пространство (из отдельных сеансов), и оба могут манипулировать и фиксировать данные в этом рабочем пространстве. Когда транзакция была завершена, вы могли затем объединить рабочее пространство с рабочим пространством LIVE, что эквивалентно выполнению фиксации в обычной транзакции.

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

Answer 2

Я использовал Hazlecast Блокировки сообщений и распределенной памяти для решения некоторых из этих проблем, однако использование такого инструмента потребовало бы повторного назначения программного обеспечения в тех частях, где вы касаетесь одних и тех же данных. Клиентские документы C ++ здесь Java-клиент здесь

Oracle также имеет аналогичный продукт под названием Oracle Coherence, который может вам помочь, см. lock в руководстве разработчика.

Кроме того, база данных содержит систему MQ под названием Oracle Streams Advanced quuing (постоянные транзакционные очереди), которая может помочь вам в некоторых ситуациях. Oracle AQ хорошо интегрируется с триггерами Oracle.

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

См. Также Программная транзакционная память

Apache Zookeeper также может помочь вам с распределенной блокировкой .

Answer 3

Я полагаю, что JBoss Transaction Manager поддерживает передачу 2pc tx через вызовы веб-служб. Вы могли бы, я полагаю, интегрировать ваши системы таким образом, но производительность снизилась бы.