Здравствуйте, ·, Вы писали:

·>Здравствуйте, CoreDumped, Вы писали:

CD>>Ситуация:
CD>>Имеется система, работающая с Ораклом под Линукс. Ядро системы написано на C и использует Embedded SQL.
CD>>Пользовательский уровень системы пишется на Java с использованием JDBC.

CD>>Проблема:
CD>>При вызове JDBC из модуля C (JNI) возникает проблема измененных данных в Оракле, т.е, предположим,
CD>>модуль C изменил поле в таблице и вызвал Java (без выполнения commit). Естественно что данное изменение
CD>>не будет "видно" в Java. Аналогично, в случае изменения в Java, изменение не будет "видно" в C.

CD>>Ограничения:
CD>>Нет возможности выполнять commit между вызовами и нет возможности 2-phase commit.
CD>>Буду признателен любой идее как убрать "берлинскую стену" между JDBC и C.
·>Как я понял, в С создаётся соединение к бд, там выполняются запросы и потом передаётся управление в java, которая имеет своё, друоге, соединение к той же БД и естесвенно уровень isolation не показывает незакомиченные данные. Я правильно понял?

·>2-PC и распределённые транзакции тут тогда вообще не в тему. Это всё о том, как сделать согласованные изменения в _разных_ БД, а у тебя как расшарить одно и то же соединение между C и java.

·>Решение может быть такое: каким-то образом протащить handle соединения из С в java. В java написать свою реализацию jdbc обвязки, адаптер, который будет проксировать вызовы из jdbc в С-шный handle соединения. Или наоборот — пусть C-шный код ходит через jdbc.
·>Может можно разворотить oracle jdbc драйвер, чтобы его как-то грязно хакнуть и через рефлексию запихать соединение из С, но это нужно будет разбираться в устройстве проприетарного кода без исходников.

·>А вообще, желательно что-то сделать такой архитектурой. Неправильно всё это.

Спасибо!
Примерно в этом направлении и думаем продвигаться. Был у Оракла т.н JDBC-ODBC мост, который позволял расшарить соединения к базе, но они прекратили его поддержку.