In che modo Spring Batch gestisce le transazioni (con possibilmente più origini dati)?

Question

Vorrei alcune informazioni sul flusso di dati in un'elaborazione di batch di primavera ma non riesco a trovare quello che sto cercando su Internet (nonostante some useful questions su questo sito).

Sto cercando di stabilire degli standard per utilizzare Spring Batch nella nostra azienda e ci stiamo chiedendo come si comporta Spring Batch quando diversi processori in un passaggio aggiornano i dati su diverse origini dati.

Questa domanda si concentra su un processo frammentato ma non esitare a fornire informazioni su altre modalità.

Da quello che ho visto (correggimi se ho torto), quando una riga viene letta, segue l'intero flusso (lettore, processori, scrittore) prima che il successivo venga letto (al contrario di un'elaborazione di silo dove il lettore dovrebbe elaborare tutte le linee, inviarle al processore e così via).

Nel mio caso, diversi processori leggono i dati (in diversi database) e li aggiornano nel processo, e infine lo scrittore inserisce i dati in un altro DB. Per ora, JobRepository non è collegato a un database, ma sarebbe indipendente, rendendo la cosa ancora un po 'più complessa.

Questo modello non può essere modificato poiché i dati appartengono a diverse aree aziendali.

Come viene gestita la transazione in questo caso? I dati vengono impegnati solo dopo l'elaborazione del blocco completo? E poi, c'è una gestione del commit in 2 fasi? Come è assicurato? Quale sviluppo o configurazione dovrebbe essere fatto al fine di garantire la coerenza dei dati?

Più in generale, quali sarebbero le vostre raccomandazioni in un caso simile?

Answer 1

Il lotto di primavera utilizza il nucleo Spring transaction management, con la maggior parte della semantica della transazione disposta attorno a un blocco di elementi, come descritto nella sezione 5.1 of the Spring Batch docs.

Il comportamento delle transazioni di lettori e scrittori dipende esattamente da quello che sono (ad es. File system, database, coda JMS ecc.), Ma se la risorsa è configurata per supportare le transazioni, verranno automaticamente inserite automaticamente in primavera. Lo stesso vale per XA: se si rende l'endpoint della risorsa conforme a XA, utilizzerà per essa due commit di fase.

Tornando alla transazione pezzo, verrà impostata una transazione su base chunk, quindi se si imposta l'intervallo di commit su 5 su un determinato tasklet, verrà aperta e chiusa una nuova transazione (che include tutte le risorse gestite da il gestore delle transazioni) per il numero impostato di letture (definito come intervallo di commit).

Ma tutto questo è impostato sulla lettura da una singola sorgente di dati, soddisfa le tue esigenze? Non sono sicuro che il batch di primavera possa gestire una transazione in cui legge i dati da più fonti e scrive il risultato del processore in un altro database all'interno di una singola transazione. (In effetti non riesco a pensare a nulla che possa farlo ...)