Archivia il file nel filesystem e i suoi metadati nel database atomicamente

Ecco una risposta parziale, ma più pratica e probabilmente applicabile. I if processi successivi considerano solo i file tramite le loro voci di metadati, quindi il caricamento dei file e l'aggiornamento ai metadati non devono necessariamente essere atomici. Ciò significa che non è possibile avere un processo che elabora tutti i file nella directory SFTP. Dovrebbe invece recuperare l'elenco dei file dalla tabella dei metadati ed elaborare ciascun file nell'elenco risultante. Allo stesso modo, non è possibile avere un processo che controlli un file specifico nella directory; dovrebbe invece controllare una voce nella tabella dei metadati.

In questo contesto, puoi semplicemente caricare il file e, una volta verificato il caricamento, inserire un record di metadati. Se il processo fallisce in qualsiasi momento prima che l'inserimento dei metadati venga eseguito, si finisce con un file orfano innocuo. Ciò presuppone che i nomi dei file siano distinti; tuttavia, se passi sempre attraverso la tabella dei metadati, i nomi dei file nella directory SFTP non sono più importanti, quindi puoi semplicemente aggiungere un UUID alla fine di essi per garantire che siano distinti.

Potresti voler eliminare gli orfani (in particolare perché "sovrascrivere" un file in questo contesto significa semplicemente rendere orfano il vecchio file). Questo può essere fatto in un processo in background che cancella i file più vecchi di un certo orizzonte temporale, che può essere probabilmente di almeno 24 ore e probabilmente dell'ordine di mesi.

Se le ipotesi non si applicano, allora qualcosa come l'approccio di Christophe diventa necessario.

Hai 3 nodi (WS, SFTB e DB), ognuno dei quali esegue una parte dell'operazione. La difficoltà è che se uno qualsiasi dei nodi fallisce, gli altri devono eseguire il rollback del lavoro parziale.

Puoi ottenere ciò ad esempio con un protocollo di commit a 3 fasi : - il tuo WS potrebbe agire da coordinatore per le transazioni avviate - SFTP e DB funzionerebbero come partecipanti

Ogni nodo deve gestire la parte della transazione da impegnare o il rollback. Questo di solito richiede una registrazione dei lavori in corso, in modo che il nodo sia in grado di annullare le modifiche se deve eseguire il rollback (e anche dopo un arresto anomalo, al riavvio del sistema).

Attenzione: in questo schema, si presume che l'SFTP carichi solo nuovi file. Se avessi diversi WS e due di loro potessero caricare un file con lo stesso nome file, l'ultimo potrebbe sovrascrivere il lavoro del primo in modo che i metadati vengano corrotti (due record di metadati non corrispondenti per un file) e l'atomicità sia interrotta.