Colega, veja bem : é um FATO que que, se vc abre várias SESSÕES num RDBMS,
naturalmente os dados inseridos por uma SESSÂO x mas ainda não comitados ** não
** podem/não vão poder ser 'enxergados' por uma outra sessão y, EM ESPECIAL no
RDBMS Oracle aonde nunca, jamais, em tempo algum, existe leitura "suja", de
dados não comitados em outra sessão.... SE a pessoa não conhece conceitos tão
fundamentais e está desenvolvendo um aplicativo com RDBMS, my god.....
Bom, sobre o seu cenário de ter diversos arquivos de dados a carregar em
paralelo (em SESSÔES diferentes no database) temos que :
a. se existe INTEGRIDADE DE DADOS (por exemplo, constraints de PK/FK) entre
dados de diferentes arquivos, OU vc assegura que os arquivos com as PKs serão
processados/inseridos primeiro, OU vc temporariamente (durante a carga) desliga
as constraints e as religa no final da carga (verificando os dados antes, é
claro) OU se viável usa delayed constraints
b) se o problema é que a sessão x está carregando o arquivo 1 e nesse momento
entra uma sessão y que tenta carregar o mesmo arquivo, CLARO que para o
database isso são sessões DIFERENTES : para vc controlar isso, vc TEM que
colocar na procedure uma "inteligência" que registre que o arquivo está sendo
processado, e portanto a sessão y TEM que "pular" ele - a maneira COMUM no
RDBMS Oracle é ter uma tabela de controle que vc locka (LOCK é o meio de se
assegurar acesso serializado, uma sessão por vez, a um dado recurso)...
Poderia existir uma tabela LISTA_DE_ARQUIVOS, com uma coluna só
NOME_DO_ARQUIVO, e essa tabela ser carregada num pré-processamento com a lista
toda dos arqs a carregar, aí a procedure teria uma lógica tipo :
BEGIN
for r in (select nome_do_arquivo from LISTA_DE_ARQUIVOS FOR UPDATE SKIP
LOCKED) loop
...
lê o arquivo registrado na coluna NOME_DO_ARQUIVO e faz os
INSERTs necessários
...
delete from LISTA_DE_ARQUIVOS where current of;
end loop;
commit;
END;
okdoc ?? Aí se uma sessão y ser disparada enquanto uma sessão x está lendo um
dado arquivo 1, a linha correspondente à ele está LOCKADA e portanto vai ser
pulada e a sessão vai processar o arquivo 2....
==> é CLARO, eu estou supondo que o que vc quer é evitar que as próximas
sessões processem o mesmo arquivo : não há necessidade, imagino, de usar a
restrição mais rígida que vc cita (ie, PROIBIR as próximas sessões de
executarem enquanto a sessão x inicial tá rodando), MAS é plenamente possível
se fazer isso, aí vc usaria um LOCK TABLE numa tabela de flag...
[]s
Chiappa
OBS : é claro, vc tem que ter CERTEZA que não há os mesmos dados, com a mesma
chave, em arquivos diferentes : é ULULANTEMENTE óbvio e conhecido que se duas
sessões fizerem simultaneamente INSERTs do mesmo dado com a mesma chave, em
condições normais de uso (ie, constraints não-delayed, etc) uma delas (a
segunda, normalmente) VAI ficar em WAIT, sim ??? E esse WAIT só será satisfeito
quando a sessão original comitar, só então a constraint vai ser ativada e o
registro é rejeitado com duplicated key....
--- Em [email protected], Carlos Silva <carlos-csilva@...> escreveu
>
> Ola pessoa!
> Estou usando o oracle 10g ... Tenho uma procedure que recebi via
> webservice arquivos, segundo informação de um rapaz que trabalha comigo, ele
> abre varias seções no oracle, e quando entra a primeira informação já entra a
> segunda, e essa segunda não consegue achar as informações da primeira que nao
> foi processada ainda. Existe alguma forma de controlar a linha de chegada
> dessas informações. Tipo, enquanto nao foi dado commit no primeiro insert nao
> entrar nenhum registro na procedure ou insert.
> At.:
>
> [As partes desta mensagem que não continham texto foram removidas]
>
