Здравствуйте, 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 драйвер, чтобы его как-то грязно хакнуть и через рефлексию запихать соединение из С, но это нужно будет разбираться в устройстве проприетарного кода без исходников.

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

Доброго дня!

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

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

Ограничения:
Нет возможности выполнять commit между вызовами и нет возможности 2-phase commit.


Буду признателен любой идее как убрать "берлинскую стену" между JDBC и C.

Спасибо!

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

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

CD>Ограничения:
CD>Нет возможности выполнять commit между вызовами и нет возможности 2-phase commit.
Интересно, как и где он вообще выполняется. Надеюсь, не по кнопке "Commit" на форме.

CD>Буду признателен любой идее как убрать "берлинскую стену" между JDBC и C.

1) Выделить DAL и изолировать его в ядре, для пользовательского уровня выставить прикладной API. Но с вашим legacy монстром наверное это нереально.

2) Выставить из ядра костыль — SQL API (как вариант, реализовать JDBC драйвер — прокси) и работать только через него. Будет много геморроя с управлением сессиями (особенно если используется пулинг и т.п.)

3) Переписать ядро на Java (или вообще на PL/SQL).

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

CD>Доброго дня!

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.

CD>Спасибо!

Может можно как-то распределенные транзакции прикрутить?

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

·>Здравствуйте, 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 мост, который позволял расшарить соединения к базе, но они прекратили его поддержку.

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

CD>·>А вообще, желательно что-то сделать такой архитектурой. Неправильно всё это.
CD>Спасибо!
CD>Примерно в этом направлении и думаем продвигаться. Был у Оракла т.н JDBC-ODBC мост, который позволял расшарить соединения к базе, но они прекратили его поддержку.
Это, вообще говоря, плохое направление, в Оракле это тоже поняли, поэтому и прекратили поддержку.
Вначале оцени, мне кажется, что дешевле будет поменять архитектуру, чтобы работа с СУБД была только в одной из частей вашей системы, а не размазана между C и Java.