declarações unidade de teste DDL que precisam ser em uma transação

Question

Eu estou trabalhando em um aplicativo que usa o Oracle é construído em mecanismos de autenticação para gerenciar contas de usuário e senhas. O aplicativo também usa segurança em nível de linha. Basicamente todos os usuários que os registos através da aplicação recebe um nome de usuário e senha do Oracle em vez da entrada típica em uma tabela de "usuários". Os usuários também recebem rótulos em certos quadros. Este tipo de funcionalidade exige que a execução de instruções DML e DDL ser combinado em muitos casos, mas isso coloca um problema porque as instruções DDL realizar commits implícitas. Se ocorrer um erro após uma instrução DDL foi executado, o gerenciamento de transações não vai rolar tudo de volta. Por exemplo, quando um novo usuário se registra com o sistema da seguinte pode ocorrer:

1. transação Iniciar
2. Insira detalhes pessoa em uma tabela. (Ou seja, nome, sobrenome, etc.) -DML
3. Crie uma conta oracle (criar testuser usuário identificado por senha;) -DDL cometer implícita. extremidades da transação.
4. New transação começa.
5. Realizar mais statments DML (inserções, atualizações, etc).
6. Erro ocorre, transação somente rola de volta para a etapa 4.

Eu entendo que a lógica acima está funcionando como projetado, mas estou achando difícil teste de unidade este tipo de funcionalidade e gerenciá-lo na camada de acesso a dados. Eu tive o banco de dados ir para baixo ou ocorrerem erros durante os testes de unidade que causaram o esquema de teste para ser contaminados com dados de teste que deveria ter sido revertida. É fácil o suficiente para limpar o esquema de teste, quando isso acontece, mas estou preocupado com falhas de banco de dados em um ambiente de produção. Estou à procura de estratégias para gerenciar isso.

Esta é uma aplicação Java / Primavera. Primavera está fornecendo o gerenciamento de transações.

Answer 1

Você deve usar a autenticação de proxy do Oracle em combinação com segurança em nível de linha.

Leia este: http://www.oracle. com / tecnologia / pub / artigos / dikmans-toplink-security.html

Answer 2

Em primeiro lugar eu tenho que dizer: má idéia fazê-lo desta forma. Por duas razões:

1. Conexões são baseados em usuário. Isso significa que você em grande parte, perder os benefícios do pool de conexão. Ele também não escala terrivelmente bem. Se você tem 10.000 usuários de uma só vez, você vai ser continuamente abrindo e fechando conexões rígidos (em vez de pools de conexão suaves); e
2. Como você descobriu, criação e remoção de usuários é DDL não DML e, assim, você perde "transacionalidade".

Não sei por que você escolheu para fazê-lo isso, mas eu faria fortemente recomendamos que você implementar usuários na aplicação e não a camada de banco de dados.

Quanto à forma de resolver o seu problema, basicamente, você não pode. Mesmo como se você estivesse criando uma tabela ou um índice no meio de sua sequência.

Answer 3

Eu vou discordar de alguns dos comentários anteriores e dizer que há uma série de vantagens para usando a segurança da conta built-in Oracle. Se você tem que aumentar isso com algum tipo de sombra tabela de usuários com informações adicionais, como sobre envolvendo a criação da conta Oracle em um pacote separado que é declarado PRAGMA AUTONOMOUS_TRANSACTION e retorna um status de sucesso / insucesso ao pacote que está fazendo a inserção em tabela de sombra? Eu acredito que este seria isolar a criação da conta do Oracle com a transação.