Событие commit;

Thin
Дата: 06.03.2011 13:15:43
Добрый день. Помогите советом плиз=)

Есть ли возможность в Oracle 10 повесить триггер на commit; или есть какие либо наработки на эту тему у кого то?
Суть задачи:
1. Есть сервер Oracle 10.
2. Есть приложение-клиент (приложение 1), которое манипулирует данными Oracle.
3. Есть приложение-клиент (приложение 2), которое предназначено для тестирования работы "приложения 1".
4. "Приложение 2" эмитирует действия пользователя, объединяя их в логические группы. Каждая логическая группа действий "приложения 2" является отдельным тестом.
5. После выполнения каждого теста "приложение 2" начинает сканировать БД, выполняя запрос результата, например раз в 2 секунду до тех пор, пока не получит результат или истечёт заданный таймаут.

Так у меня эта система работает сейчас. Для увеличения производительности и снижения нагрузки на БД, я решил реализовать обратную связь с БД:
Добавил в текст триггеров изменения / вставки строк, вызов Java процедуры, которая открывает сокет с "приложением 2" и передаёт сообщение "приложению 2" о том что в БД произошло изменение данных. После чего "приложение 2" выполняет запрос в БД на получение результата теста.

Проблема, такой реализации обратной связи с БД, оказалась в том что, БД сообщает "приложению 2" об изменении данных "слишком рано". Т.е. commit-а ещё не было (а при откате и не будет никогда), а "приложение 2" уже получило сообщение об изменении => "приложение 2" лезет в БД и ничего там не обнаруживает!

Может быть в Oracle есть какие то стандартные приёмы и механизмы, позволяющие поймать событие "подтверждённых" изменений данных.

Решение: вмешаться в тестируемый код, добавив вызов Java процедуры после "commit;" , в силу ряда причин, не подойдёт.
Вмешательство в "тестируемый код" не подходит, т.к.
1. это будет уже не "чистое" тестирование.
2. в некоторых случаях это сделать невозможно.

Буду благодарен за ваши подсказки!
suPPLer
Дата: 06.03.2011 13:43:05
По-моему, у Вас странно поставлен процесс тестирования. Зачем вся эта обратная связь с приложением-тестом? Оно выполнило необходимые операции (которые что-то там поменяли в БД и зафиксировали изменения), затем сравнило результат выполнения запроса с эталоном. Зачем в цикле до победного конца выполняется запрос, тоже непонятно. У Вас асинхронная работа с БД в тестовом приложении, что ли?
Thin
Дата: 06.03.2011 14:04:12
Да, вы совершенно правы suPPLer. Приложение-тест работает с БД асинхронно. Это происходит по той причине, что "приложение-тест" работает в следующей последовательности:
1. посылает команды (эмитируя пользователя) на "приложение 1".
2. "Приложение 1" в ответ на эти команды "что то" делает с БД. Связь "приложения-тест" с "приложением 1" односторонняя => "приложение-тест" не знает когда "приложение 1" закончит работу с БД => из за чего и получается асинхронная работа "приложения-тест" с БД.
-2-
Дата: 06.03.2011 14:08:06
Thin,

dbms_alert
andreymx
Дата: 06.03.2011 14:10:30
-2-
Thin,

dbms_alert
придется менять тестируемое приложение, а ТС против
Thin
Дата: 06.03.2011 15:02:03
andreymx, если идёт речь об изменении текста триггеров, то это сделать возможность есть =)

Если не сложно, напишите простейший пример использования этого пакета или ссылочку какую...

Вот нарыл пример

CREATE TRIGGER emptrig AFTER INSERT OR UPDATE OR DELETE ON emp
    BEGIN 
      DBMS_ALERT.SIGNAL('emp_table_alert', 'message_text'); 
   END;

а чего с ним дальше то делать? Я правильно понял- после фиксированных изменений таблицы, объекту 'emp_table_alert' передаётся сообщение 'message_text'? А как прицепиться к этому событию? куда впихнуть кастомную процедуру рассылки сообщения на внешний клиент? И как создать объект 'emp_table_alert'?

Только не закидывайте меня тапками пожалуйста, типа иди читай 10 000 страниц мануала по Oracle на английском языке =)
suPPLer
Дата: 06.03.2011 15:09:15
Thin,

можно через джобы в триггерах.
Thin
Дата: 06.03.2011 15:57:38
suPPLer, да, это интересное предложение!

Надо попробовать. С учётом того, что после выполнения большинства процедур пакета DBMS_JOB требуется commit; , изменение и запуск джоба будут выполнятся в той же транзакции что и изменение основных данных.
Надеюсь этот пакет не слишком сильно будет скорость просаживать...
SY
Дата: 06.03.2011 15:59:18
What about materialized view with refresh on commit. You will have to change:

"Добавил в текст триггеров изменения / вставки строк, вызов Java процедуры, которая открывает сокет с "приложением 2" и передаёт сообщение "приложению 2" о том что в БД произошло изменение данных"

to:

1. "Добавил TEST_SEQUENCE table"
2. "Добавил materialized view on TEST_SEQUENCE table with on commit refresh"
3. "Добавил в текст триггеров изменения / вставки строк insert into TEST_SEQUENCE table (you could even use some value uniquely identifying particular test)"
4. "Добавил триггер on materialized view вызов Java процедуры, которая открывает сокет с "приложением 2" и передаёт сообщение "приложению 2" о том что в БД произошло изменение данных".

SY.
Thin
Дата: 06.03.2011 16:41:19
SY, спасибо! С материализованным представлением элегантное решение.
Обязательно попробую! В голову бы даже не пришло.