Processamento em Lote sem transação global

Programação Arquitetura
#1

Bom dia pessoal
Estou precisando fazer um operação em lote com um SGDB no qual cada operação individual tem obrigatoriamente sua transação separada. O problema seria o seguinte:

  • A operação em lote pode durar minutos com centenas de registros.
  • Cada operação tem sua transação individual - begin e commit dentro do sgdb e NÃO TEM COMO fazer uma transação GLOBAL. (sistema legado)
  • Como fazer roolback das operações que já foram commitadas em caso de uma no final falhar?
    Alguém sabe de algum pattern ou estratégia para isso?
#2

não ficou claro, seu 3o requisito diz pra ter controle de rollback global, mas você quer transação local?

#3

Fala brow…vou explicar o cenário.
Existe um sistema legado de 15 anos que tem um procedure que dentro dela tem escopo com a transação begin() varios inserts commit().
Em em novo sistema agora em java, tem uma operação em lote que vai chamar a procedure centenas de vezes…
O problema é que caca chamada comita a transação…se der pau na ultima eu não consigo dar roolback nas que ja foram executadas.

#4

vejo como soluções:
-ou cria uma transação externa de tal modo que as internas sejam aninhadas, daí o rollback da externa retorna também as externas
-alterar o codigo do sistema anterior isolando o trecho que realiza as operações, de tal modo que o codigo original chama tal fragmento, e voce vai invocar da sua aplicação nova esta tal fragmento.

Não vejo outras opções agora.

#5

[quote=FernandoFranzini]
O problema é que caca chamada comita a transação…se der pau na ultima eu não consigo dar roolback nas que ja foram executadas.[/quote]

pra isso que serve uma transação global. Algum motivo pra vc não poder criar uma?

#6

[quote]-ou cria uma transação externa de tal modo que as internas sejam aninhadas, daí o rollback da externa retorna também as externas
[/quote]
SGDB não suporta transações aninhas…bem poucos SGDB hoje suportam isso…

[quote]-alterar o codigo do sistema anterior isolando o trecho que realiza as operações, de tal modo que o codigo original chama tal fragmento, e voce vai invocar da sua aplicação nova esta tal fragmento.
[/quote]Não podemos…protegido por contrato…

#7

[quote=JDesenvolvedor][quote=FernandoFranzini]
O problema é que caca chamada comita a transação…se der pau na ultima eu não consigo dar roolback nas que ja foram executadas.[/quote]

pra isso que serve uma transação global. Algum motivo pra vc não poder criar uma?[/quote]
Transação global? isso é recurso especifico de SGDB? favor esclarecer…

#8

[quote=FernandoFranzini][quote=JDesenvolvedor][quote=FernandoFranzini]
O problema é que caca chamada comita a transação…se der pau na ultima eu não consigo dar roolback nas que ja foram executadas.[/quote]

pra isso que serve uma transação global. Algum motivo pra vc não poder criar uma?[/quote]
Transação global? isso é recurso especifico de SGDB? favor esclarecer…[/quote]

É um recurso de qualquer sistema Java EE, isso é, se o sistema for projetado independente de questões de infraestrutura (como transações) você pode configura-lo com outro contexto transacional durante o deploy, não precisa alterar código nenhum.

#9

Uma solução seria transformar essa procedure em código java e fazer tudo oq tem q fazer, todas as operações em java e depois comitar a transação. O único problema é se essa procedure for grande igual o capeta, vai dar mó trabalho rsrs.

#10

As sub-transações precisam necessariamente rodar “tudo ou nada”? Se ficar com algumas completadas e outras não isso seria considerado um estado de inconsistência no sistema?

Se não for esse o caso daria para implementar um controle de status individual, que marcasse as sub-transações como completadas, permitindo tratar as demais depois.

#11

JDesenvolvedor
que eu saiba depois de comitar uma store procedure não existe como voltar atrás, é diferente de vc ter varios inserts e update, em vários bancos ao mesmo tempo, isso feito em java funciona, agora Store procedure acho que não, correto?

#12

Eu ja to usando amigo…JTA com Spring.
O problema que é dentro da procedure tem uma transação manual que abre e comita por conta.
Esse é o problema…

#13

Olá
Perguntas:

  • você consegue (ou está com) acesso exclusivo ao banco?
  • você tem operações reversas (“desfaz”) ao que está fazendo?
  • você consegue consistir o lote, para verificar se vai conseguir processar? Uma transação do início do lote pode deixar uma transação posterior inconsistente?
#14

Das varias opções que apareceu, decidimos duplicar a procedure, sem o comando de transação, uma vez que esse novo processo, precisou de uma variação um pouco diferente da procedure existente. Ainda bem que isso aconteceu, senão ja estava partindo para uso de mensageria.
Obrigado pelo ajuda pessoa.

#15