Тестирование модулей DDL-операторов, которые должны быть в транзакции

Question

Я работаю над приложением, использующим встроенные механизмы аутентификации Oracle для управления учетными записями пользователей и паролями. Приложение также использует безопасность на уровне строк. В основном каждый пользователь, который регистрируется через приложение, получает имя пользователя и пароль Oracle вместо обычной записи в таблице «ПОЛЬЗОВАТЕЛИ». Пользователи также получают метки на определенных таблицах. Этот тип функциональности требует, чтобы выполнение операторов DML и DDL было объединено во многих случаях, но это создает проблему, поскольку операторы DDL выполняют неявные коммиты. Если ошибка возникла после выполнения инструкции DDL, управление транзакциями не откатит все. Например, когда новый пользователь регистрируется в системе следующих может иметь место:

1. Начало транзакции
2. Вставьте персоны детали в таблицу. (т. е. имя, фамилия и т. д.) -DML
3. Создать учетную запись oracle (создать пользовательский идентификатор пользователя, идентифицированный по паролю;) -DDL неявный фиксация. Транзакция заканчивается.
4. Новая транзакция начинается.
5. Выполните больше записей DML (вставки, обновления и т. Д.). происходит
6. Ошибки транзакции только откат к шагу 4.

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

Это приложение Java/Spring. Spring предоставляет управление транзакциями.

Answer 1

Вы должны использовать аутентификацию прокси-сервера Oracle в сочетании с безопасностью на уровне строк.

Прочитайте это: http://www.oracle.com/technology/pub/articles/dikmans-toplink-security.html

Answer 2

Прежде всего я должен сказать: плохая идея, делающая это так. По двум причинам:

1. Соединения основаны на пользователе. Это означает, что вы в значительной степени теряете преимущества объединения пулов. Он также не масштабируется ужасно хорошо. Если у вас сразу 10 000 пользователей, вы будете постоянно открывать и закрывать жесткие соединения (а не пулы мягких подключений); и
2. Как вы обнаружили, создание и удаление пользователей - это DDL, а не DML, и поэтому вы теряете «транзакцию».

Не знаю, почему вы решили сделать это это, но я бы сильно рекомендуем осуществлять на пользователей приложения, а не слой базы данных.

Как решить вашу проблему, в принципе вы не можете. Точно так же, как если бы вы создавали таблицу или индекс в середине вашей последовательности.

Answer 3

Я не согласен с некоторыми предыдущими комментариями и скажу, что есть много преимуществ в использовании встроенной безопасности учетной записи Oracle. Если вам нужно увеличить это с помощью какой-либо теневой таблицы пользователей с дополнительной информацией, как насчет обертывания создания учетной записи Oracle в отдельном пакете, который объявлен PRAGMA AUTONOMOUS_TRANSACTION, и возвращает статус sucess/failure в пакет, который выполняет вставку в теневой стол? Я считаю, что это изолирует создание учетной записи Oracle из транзакции.