Processamento de falha de reversão de primavera recentemente, eu estava trabalhando em um projeto e acidentalmente descobriu que uma aula estava jogando operação de reversão de coisas, e os dados eram inseridos no banco de dados normalmente, então eu cuidadosamente verifiquei e olhei para o motivo específico.
Tudo ainda começa com as exceções verificadas de Java e exceções não verificadas.
Então, o que é uma exceção do tipo de inspeção e o que é uma exceção do tipo de inspeção?
Existem dois pontos de julgamento mais simples:
1. A exceção que não verifica herdou a partir da RunTimeException ou erro, enquanto a exceção de verificação herdada da exceção (é claro, a própria RuntimeException também é uma subclasse de exceção).
2. Exceções não verificadas podem ser capturadas sem ser capturadas, enquanto exceções verificadas devem ser processadas com tentativa ... Catch Declaração Block ou entregue a exceção ao método superior para o processamento. Em resumo, o código deve ser gravado para processá -lo.
A estrutura de exceção do Java é mostrada na figura abaixo. Entre eles, exceções de que a exceção diretamente herdam devem ser capturadas e são verificadas exceções.
Vamos olhar para o meu código:
1. O nome do método é precedido por
@Transaction
2. O arquivo de configuração da primavera ApplicationContext-xxx.xml também possui configurações relacionadas para as coisas da primavera.
<bean id = "transactionManager"> <propriedade name = "DataSource" ref = "DataSource"/> <propriedades name = "rollbackoncommitfailure" value = "true"> </propriedade> </i bean>
Mas por que a coisa que foi enviada após a exceção de tentativa ... Exceção de arremesso não é revertida quando o método da camada de serviço é chamado?
Depois de verificar a documentação relevante da primavera, descobri que o gerenciamento de transações declarativo da primavera original realizou reversão de transações em exceções não verificadas e exceções no tempo de execução por padrão, enquanto não há reversão nas exceções verificadas.
A exceção lançada por Try ... Catch in the Code é uma exceção do tipo de verificação. A estrutura da primavera não recairá por padrão.
Na programação, exceções não verificadas podem ser evitadas, enquanto exceções verificadas devem ser processadas com blocos de instrução Try ou entregues ao método superior para lidar com eles. Em resumo, o código deve ser gravado para processá -los.
Portanto, a exceção deve ser capturada no serviço e depois lançar manualmente uma exceção não verificada para que a transação possa entrar em vigor. Por exemplo:
tente {………} Catch (Exceção e) {……… jogue nova BusinessException (e.getMessage ()); }Obviamente, temos uma maneira mais fácil de resolver esse problema, ou seja, altere o método de reversão padrão anotando parâmetros.
Norollbackfor e Rollbackfor são definidos na anotação @Transaction para especificar se uma certa exceção é revertida.
Use exemplos:
@Transaction (Norollbackfor = RunTimeException.class)
@Transaction (rollbackfor = excepcion.class)
Portanto, na pergunta acima, você pode adicionar diretamente o parâmetro de reversão @transaction (rollbackfor = excepcion.class), que altera o método de processamento de transação padrão.
Revelação:
Isso exige que herdemos a exceção personalizada da RunTimeException ao personalizar a exceção, para que, quando arremessado, ela seja tratada com precisão pelo processamento de transações padrão da Spring.
Resumir
O exposto acima é o conteúdo inteiro deste artigo sobre o problema da falha da reversão de transações Java. Espero que seja útil para todos. Amigos interessados podem continuar se referindo a outros tópicos relacionados neste site. Se houver alguma falha, deixe uma mensagem para apontá -la. Obrigado amigos pelo seu apoio para este site!