A palavra- chave Oracle PL/SQL AUTONOMOUS_TRANSACTIONfará com que um procedimento crie outra sessão, faça uma transação, confirme/reverta apenas essa transação privada e retorne o controle de fluxo de volta ao pai.

Oh..nunca envie e-mail sobre dados não confirmados.

EDIT: (devido à edição do post original)

Aproximadamente o mesmo problema surge se você deseja importar arquivos de um diretório. Se você excluir o arquivo dentro da transação, a transação poderá falhar e o arquivo foi excluído, mas nunca importado. Ou você exclui o arquivo após a transação. Em seguida, a exclusão do arquivo pode falhar e o arquivo é importado uma segunda vez.

Esse tipo de problema é chamado de bug.

A solução é:

• Defina cada etapa como suaTRANSACTION
  • Você desejará criá-los de forma que possa executar novamente (ou pular) as etapas conforme necessário
• Execute cada etapa na ordem apropriada.
  • não envie e-mail antes de COMMIT.
  • não exclua um arquivo antes do carregamento bem-sucedido dos dados
• Você precisará acompanhar "onde você está" e se essa etapa passou/falhou.

Exemplo de e-mail

Você deve ter um procedimento sendEmailque deve ser chamado após commit.

Se você quiser chamar o procedimento antes de commit, precisará adicionar uma linha a uma fila que rollbackacompanhará a transação principal. Para Oracle, isso será Advance Queuingou o pacoteAPEX_MAIL

Ao colocá-lo em um procedimento separado, você pode fazer sendEmailuma segunda vez a pedido do [usuário final].

Arquivo de processo

Você tem um algoritmo que contém algumas etapas em que cada etapa pode falhar. isso é realmente diferente do seu sendEmailproblema.

Você precisa registrar o que está processando, onde está no seu algoritmo e se essa etapa foi bem-sucedida ou falhou.

Para se recuperar de um erro em qualquer etapa, cada etapa do processo precisa ser definida como um TRANSACTION.

No Oracle, eu teria esses procedimentos (1 procedimento por TRANSACTION):

create or replace
package file_processing_package
as
  procedure update_file_processing_status(
                                p_id       IN files_to_process.id%TYPE
                              , p_status   IN process_states.id%TYPE);


  function add_a_file_to_be_processed( p_filename IN files_to_process.file_name%TYPE )
                               return files_to_process.id%TYPE;

  procedure load_data_from_file( p_id in files_to_process.id%TYPE );

  procedure process_already_loaded_data( p_id in files_to_process.id%TYPE );

  procedure delete_file_from_os( p_id in files_to_process.id%TYPE );
end;
/

Isso é baseado nas seguintes tabelas:

CREATE TABLE PROCESS_STATES (
  id   int generate by default on null as identity, -- 12c+
  state_desc  varchar2(25) not null,
  constraint process_states_pk primary key (id),
  constraint process_states_uq1 unique (state_desc)
);

insert into process_states( state_desc ) values ( 'file to be processed' );
insert into process_states( state_desc ) values ( 'file loaded' );
insert into process_states( state_desc ) values ( 'processing' );
insert into process_states( state_desc ) values ( 'processing failed' );
insert into process_states( state_desc ) values ( 'processing succeeded' );
insert into process_states( state_desc ) values ( 'delete failed' );
insert into process_states( state_desc ) values ( 'OK' ); -- delete succeeded
commit;

CREATE TABLE FILES_TO_PROCESS (
  id               int generate by default on null as identity, -- 12c+
  file_name        varchar2(50) not null,
  process_state_id int not null,
  constraint file_to_process_pk  primary key (id),
  constraint file_to_process_uq1 unique (file_name),
  constraint file_to_process_fk1 foreign key (process_state_id)
                            references (process_states.id)
);

A UNIQUErestrição on FILE_NAMEimpede que o mesmo arquivo seja processado duas vezes.

Acho que talvez o termo que você está procurando seja leitura suja :

Uma leitura suja (também conhecida como dependência não confirmada) ocorre quando uma transação tem permissão para ler dados de uma linha que foi modificada por outra transação em execução e ainda não confirmada. [...]

Em nosso exemplo, a transação 2 altera uma linha, mas não confirma as alterações. A transação 1 lê os dados não confirmados. Agora, se a Transação 2 reverter suas alterações (já lidas pela Transação 1) ou atualizar diferentes alterações no banco de dados, a visualização dos dados pode estar errada nos registros da Transação 1.

Você está descrevendo uma transação distribuída . Observe que o termo "transação" tem um significado mais geral do que simplesmente "transação de banco de dados".

Em uma transação distribuída, diferentes membros podem ter diferentes propriedades ACID (por exemplo, e-mail não é necessariamente garantido para ser entregue), diferentes abordagens para alcançar essas propriedades e diferentes cenários de falha.

Para garantir a consistência de uma transação distribuída, uma entidade externa chamada coordenador de transação (ou gerente) é normalmente empregada para controlar o comprometimento de cada membro (também pode ser chamado de recurso ou gerenciador de recursos). Um método comum é o two-phase commit (2PC).

Se você pesquisar por "consistência em sistemas distribuídos" na internet, encontrará uma grande variedade de materiais sobre o assunto.

O que você descreve é ​​o desejo de uma transação distribuída, só que você não tem um gerenciador de transações distribuído e nenhuma possibilidade de reversão. O mais fácil é usar a queue ( external ) ou o sql server broker para desacoplar o loop do envio real. Veja por exemplo: http://python-rq.org/

Não tenho um termo específico para a combinação real de invocar um processo externo de uma transação de banco de dados, mas classificaria esse problema como fortemente acoplado .

A raiz do problema é que você acoplou fortemente o envio do e-mail com a transação do banco de dados.

Uma solução para este problema será acoplá-los frouxamente .

Tecnicamente, você pode resolver isso de várias maneiras, em ordem aproximada de feio a bonito:

• um sinalizador nas linhas da tabela para indicar se um email foi enviado ou não. Um processo externo pode pesquisar sinalizadores e enviar e-mails.
• gerar e armazenar os e-mails em uma tabela. Estes serão então confirmados na mesma transação. Um processo externo lê e envia e-mails que precisam ser enviados. O monitoramento da tabela pode ser feito com sondagem ou com uma construção de escuta/notificação (veja a seguir).
• use uma construção de escuta/notificação (implementação do Postgres). A transação do banco de dados chama NOTIFY. Um processo de LISTENing que é executado continuamente é NOTIFICADO quando a transação é confirmada, fornecendo o isolamento desejado e o acoplamento fraco .

Compromissos implícitos

Eu acredito que é o termo que você está procurando. Estas são declarações que podem/podem e não irão aderirTransactions

Oráculo

MySQL

Servidor SQL

database-ddls-and-implicit-commit

e o mais interessante Isto:

sp_send_dbmail (Transact-SQL)

Ao executar sp_send_dbmail sem um contexto de transação, o Database Mail inicia e confirma uma transação implícita. Ao executar sp_send_dbmail de dentro de uma transação existente, o Database Mail depende do usuário para confirmar ou reverter quaisquer alterações. Ele não inicia uma transação interna.

O Workflow só precisa de atenção,

Ao invés de

• Início da transação
• O correio é enviado
  • Outras coisas são feitas (dentro do DB)
    • Algo dá errado
• Reverter.

TENTAR

• Enviar e-mail "Iniciando com estatísticas de instantâneo" (capturar a contagem de linhas inicial para uma variável A ou arquivo)
• Início da transação
  • Outras coisas são feitas (dentro do DB)
    • Algo dá errado.
• Reverter.
• Enviar e-mail "Terminando com estatísticas de instantâneo"

(Capturar a contagem de linhas finais para uma variável B ou arquivo)

e se as variáveis ​​A e B corresponderem, você saberá que há um erro.

Altere o fluxo de trabalho e tente usar o que você já tem a seu favor, comparação de variáveis ​​etc.

Este é um problema que não foi considerado na fase de "Engenharia de Requisitos" do projeto. Não deve ser visto como um problema do sistema de banco de dados, porque o banco de dados está funcionando como deveria. O email é enviado porque (ainda) não faz parte da lógica de negócios correta.

É chamado de falha de lógica de negócios ou possivelmente até mesmo um problema de lógica de negócios .

Logíca de negócios

Em software de computador, lógica de negócios ou lógica de domínio é a parte do programa que codifica as regras de negócios do mundo real que determinam como os dados podem ser criados, armazenados e alterados. Ele é contrastado com o restante do software que pode se preocupar com detalhes de nível inferior de gerenciamento de um banco de dados ou exibição da interface do usuário, infraestrutura do sistema ou geralmente conectar várias partes do programa.

Referência: Business Logic (Wikipedia.org)

Falhas / problemas de lógica de negócios

Os aplicativos da Web tornaram-se o mecanismo central para os processos de negócios na Internet. À medida que mais e mais empresas estão migrando para o modelo da Internet, isso levou a vários problemas e vulnerabilidades de segurança da informação. SQL Injection, Cross Site Scripting, Remote Code Execution, para citar alguns. No entanto, além das vulnerabilidades convencionais, existem muitas formas de vulnerabilidades de lógica de negócios comumente exploradas por invasores. Essas vulnerabilidades são rotineiramente ignoradas durante o controle de qualidade porque o processo destina-se a testar o que um pedaço de código deve fazer e não o que pode ser feito para fazer. O(s) outro(s) problema(s) com as falhas de lógica de negócios é que os scanners não podem identificá-las, o IDS não pode detectá-las e os firewalls de aplicativos da Web não podem defendê-las.

Assim, as vulnerabilidades da lógica de negócios são formas de usar o fluxo de processamento legítimo de um aplicativo de uma forma que resulta em uma consequência negativa para a organização. Automatizar processos de negócios, como pedidos de compra de clientes, consultas bancárias, transferências eletrônicas ou leilões online, por exemplo, exige que as entidades tenham acesso a informações extremamente confidenciais. A implementação inadequada destes pode levar a falhas na lógica de negócios.

Referência: Vulnerabilidades de lógica de negócios e alguns cenários comuns de falhas de lógica de negócios (Comunidade de segurança cibernética)

"Lógica de negócios é o comportamento pretendido do aplicativo", explicou Dan Kuykendall, co-CEO e CTO da NT OBJECtives. "É a funcionalidade que governa o núcleo do que o aplicativo faz, por exemplo, quais usuários podem ver o que, quanto os usuários são cobrados por vários itens, etc. Ataques de lógica de negócios são coisas que você pode fazer para explorar a lógica e trapacear o aplicativo... (eles) são difíceis de testar porque exigem um entendimento do aplicativo e da segurança. Em muitos casos, as equipes de controle de qualidade conhecem a lógica de negócios, mas não são especialistas em segurança e não foram treinadas no técnicas de ataque inteligentes."

Referência: falhas comuns de lógica de negócios que comprometem a segurança do aplicativo (SecurityWeek.com)