- Spegnimento
- 2 settembre 2026 alle ore 02:43 UTC
- Autore
- Kamo
- Impegno
- 6906043
deleteBy ArticleUidAndLocale è una query @Modifying e JPA rifiuta di eseguire uno fuori da una transazione. Niente su questo percorso mai aperto uno, così ogni locale di ogni articolo ha lanciato TransactionRequiredException -- "Eseguire un update/delete query" -- che il loop catturato per locale, connesso a WARN, e passato. La base di conoscenza serve l'inglese ad ogni locale da allora la caratteristica spedita, e la spazzata di dieci minuti è stata riprodotta Tutto il corpus per sempre perche' niente e' mai rimasto bloccato. Trovato guardando i registri durante un'importazione: 21 fallimenti per articolo, ogni articolo, ogni riprovazione. Ogni locale ora funziona nella propria transazione, tramite TransactionTemplate piuttosto che @Transactional sul metodo. Il confine deve essere per locale -- uno transazione intorno a tutti 21 significa un singolo fallimento locale rotola indietro i venti che ha funzionato -- e un auto-invocato helper avrebbe bypassato il proxy in esattamente modo che ha prodotto il bug @Async in questo stesso file. La chiamata traducibile rimane al di fuori della transazione. È una richiesta HTTP a un altro servizio con un timeout di lettura di 120 secondi e tenendo un database il collegamento attraverso di esso legare la piscina per la durata. Inoltre: l'esecutore asincastro cade sulla saturazione invece di correre sul chiamante. CallerRunsPolicy è di solito giusto, ma il chiamante qui è il thread Tomcat che ha appena salvato un articolo, e consegnarlo 21 chiamate HTTP è lo stallo esatto questo lavoro è stato spostato dal thread di richiesta per evitare. La spazzata è una vera percorso di recupero, non una speranza -- differire in esso non è lo stesso come cadere lavorare sul pavimento.