Коллеги, привет.
У нас есть две (больше) базы данных на оракле. Сейчас для одновременного внесения изменений мы используем DB-LINK, и считаем (может быть наивно?), что одновременное (по обеим базам) завершение (или откат) транзакции гарантирует оракл.
Обработчики часто внешние, и написаны на джаве (в джаве я ноль, увы).
Время от времени с дб-линками бывают некоторые проблемы: например не отследили зависимости между базами, и руководство сильно хочет отказаться от дб-линков. Якобы джава умеет ходить в 2 базы одновременно, джава умная, а значит джава должна уметь делать распределённую транзакцию по двум базам.
У меня смутные сомнения, что такое вообще возможно. Или я настолько отстал от жизни, и не знаю, что это делается легко и непринуждённо?
Ткните пальцем, что гуглить? Ну или прямую ссылку. Был бы премного благодарен.
Задача не совсем моя, джавистов вокруг достаточно много. Но парни молодые, горячие, готовы сразу всё шашкой порубить. Но на мои осторожные вопросы, а что будет с целостностью данных если вот в этот неприятный момент джава упадёт - ответить никто не может. Ну или ответы в стиле: а что бы она тут упала?
Хочется помочь парням не вляпаться ногами в жир.

Видимо проблема у меня в том, что я не понимаю, как в распределённых транзакциях работает двухфазный коммит в случае сбоев. И уже не важно, как были связаны две БД: через дб-линк или внешним приложением на джаве.
Всё, что я нашёл в гуглах - это общие слова: менеджер транзакций (мастер) опрашивает ресурсы (подчинённые сервера) о готовности закоммитить транзакцию (xa_prepare), а потом их все последовательно коммит (xa_commit).
Тонкостей я пока не нашёл (мало искал?). Вдруг подскажете, что будет в таком случае:
1) конфигурация из трёх серверов: один мастер, и два слейва: слейв1 и слейв2.
2) xa_prepare - все готовы
3) xa_commit для слейва1 - ок.
4) в "короткий неприятный момент" так неприятно совпало, что мастер падает: ну кто-то его убил, или там утечка памяти, или что-то ещё неприятное.
5) до того момента, пока мастер не поднимется, и вспомнит, что у него не докачена транзакция на слейве2 - мы имеем расхождение целостности данных в слейве1 и слейве2 - так ведь? Неприятно.
Это как бы не очень страшно, если в мастере есть БД, которая помнит, где и что мы не успели закоммитить. Видимо если мастер - на базе оракла (дб-линки) - то там это запомнить просто.
А вот если мастером (менеджером транзакций) выступает приложение на джаве - то оно-то где это всё помнит? Там какая-то своя маленькая БД есть для таких случаев?
Понятно, что эти "короткие неприятные моменты" - маловероятны. Но мы же помним про законы Мерфи. У нас, например, на промышленной системе с не очень-то и большим количеством пользователей уже возникали крайне маловероятные ситуации. Например пользователь нажимал кнопку "отменить" (oracle user requested cancel of current operation) в момент работы блока инициализации пакета, что на 11 оракле приводило к интересным последствиям. Вот я теперь и охотно верю в возможность маловероятных моментов.