- Navios
- 2 de setembro de 2026 às 02:43 UTC
- Autor
- Kamo
- Enviar
- 6906043
deleteByArticleUidAndLocale é uma consulta @Modificing e JPA se recusa a executar uma fora de uma transacção. Nada neste caminho nunca abriu um, então cada local de cada artigo lançou TransactionRequiredException -- "Executar um update/delete query" -- que o loop capturado por locale, logado em WARN, e Passou. A base de conhecimentos tem servido inglês para todos os locais desde o recurso enviado, e a varredura de dez minutos foi re-tentando o todo o corpus para sempre porque nada do que ele fez nunca ficou preso. Encontrado observando os logs durante uma importação: 21 falhas por artigo, cada artigo, cada repetição. Cada locale agora é executado em sua própria transação, via TransactionTemplate rather do que @Transactional no método. O limite tem de ser por localidade -- um transação em torno de todos os 21 significa uma única falha locale volta a vinte que funcionou -- e um ajudante auto-invocado ignoraria o proxy exatamente no forma que produziu o bug @Async neste mesmo arquivo. A própria chamada de tradução fica fora da transação. É um pedido HTTP para outro serviço com um tempo limite de leitura de 120 segundos, e com uma base de dados ligação através dele iria amarrar a piscina para a duração. Além disso: o executor assync cai na saturação em vez de correr na chamada. CallerRunsPolicy normalmente está certo, mas o chamador aqui é o tópico Tomcat que acabou de salvar um artigo, e entregá-lo 21 chamadas HTTP é o exato stall este trabalho foi retirado da linha de solicitação para evitar. A varredura é real caminho de recuperação, não uma esperança -- adiar para ele não é o mesmo que cair Trabalhar no chão.