La soluzione migliore per una transazione di database di grandi dimensioni

Question

La soluzione migliore per una transazione di database di grandi dimensioni

#1 da (3 voti)
#2 da (3 voti)

4

Ho un processo COBOL CICS in esecuzione su un sistema legacy mainframe. Il processo esegue oltre 2K DML in un ambiente DB altamente concorrente. Dopo ogni operazione CRUD, il risultato viene utilizzato per eseguire ulteriori calcoli seguiti di nuovo dalle operazioni CRUD. L'intero processo viene eseguito sotto un blocco di transazione in modo tale che qualsiasi errore prima del completamento con esito positivo comporti il rollback dell'intero set di modifiche del DB, solo in caso di esito positivo di ogni fase del processo fino alla fine, esiste un commit. Il programma COBOL è scritto in modo da non consumare più di 20 secondi dispari per il suo completamento o guasto, nel caso che l'altro processo muoia di fame per la risorsa DB (serrature, bancarelle, ecc.) A causa dell'enormità di questa transazione.

Ora ci viene commissionato di esporre questa applicazione legacy come servizio web Java SOAP. I tre approcci che ho sono:

Il livello di servizio del mio codice Java invia un messaggio alla coda con parametri di input, il programma COBOL già esistente preleva il messaggio dalla coda e fa la transazione. Il livello Java esegue il ping della coda in modo asincrono e quando ha ottenuto un risultato dal processo COBOL, lo rimanda al Controller.
Scrivi una stored procedure che imita il lavoro eseguito dal processo COBOL inclusa la transazione del DB e chiama tale SP dal livello del servizio Java.
Scrivi la logica di business all'interno del livello Java Service / DAO e le transazioni all'interno di un blocco di transazione Spring.

L'azienda non vuole l'approccio numero 1 in quanto significa dipendenza dal programma COBOL legacy. Ho due dubbi qui:

Ho capito che gli SP sono migliori dal punto di vista delle prestazioni. Ma l'SP sarà in grado di gestire 2K o più DML dispari all'interno di un blocco di transazione e fare il lavoro in tempo almeno equivalente al tempo impiegato dal processo COBOL? Se sì, allora sarà abbastanza efficiente nel bloccare il rilascio di risorse DB poiché il DB è altamente concorrente e non voglio che altri processi muoiano di fame a causa di esso.
Non ho mai eseguito una transazione DB di questa portata dal codice Java e dubito che il blocco di transazione Spring possa contenere efficacemente DML 2K in un singolo blocco. Anche se lo fosse, sono sicuro che non corrisponderebbe alla velocità di COBOL o SP, quindi potrebbe acquisire blocchi su record ecc. E morire di fame altri processi che devono accedere allo stesso per molto tempo.

Le transazioni non si trovano su una particolare tabella DB, è distribuita su 20 diverse tabelle dispari contenenti dati finanziari critici. Stavo pensando di interrompere il gran numero di operazioni CRUD in blocchi di blocchi di Spring, ma sarebbe stato un compito enorme codificare l'intera logica di rollback in Java, ma va bene, la mia preoccupazione principale è bloccare altri processi da DB accesso nel frattempo.

Sono uno sviluppatore Java con scarsa conoscenza di RDBMS e praticamente nessuna conoscenza di COBOL. Sarei grato se qualcuno potesse aiutarmi a indicare la direzione giusta in modo che io possa uscire da solo con una soluzione.

rdbms spring stored-procedures transaction cobol

posta NINCOMPOOP 27.08.2014 - 18:38

fonte

2 risposte

Leggi altre domande sui tag rdbms spring stored-procedures transaction cobol

È una cattiva pratica utilizzare un nodo vuoto con attributo valore in XML? [duplicare] Perché non ci sono puntatori a funzioni in Java? [chiuso]

score 3 · Answer 1

Una delle promesse di SOA è sfruttare i sistemi legacy attraverso un livello di astrazione e un bus di servizio.

Per prima cosa chiedi business ti chiede di esporre l'applicazione legacy come server Web, ma poi dici che la business non vuole l'opzione n. 1 perché dipende dal programma COBOL legacy. Quindi ciò che ti chiedono davvero è di riscriverlo .

In tal caso, l'approccio migliore è # 2, riscrivi la cosa nelle stored procedure.

Questo ha i seguenti vantaggi rispetto all'approccio Java / DAO:

Linguaggi orientati alla memorizzazione come PL / SQL, PL / PgSQL o Transact SQL (non si indica quale RDBMS si sta utilizzando), essendo specifico-specifico (come opossed a scopo generale) sono più simili a COBOL di Java. Hanno un set di istruzioni più piccolo, una grammatica più semplice e, in generale, sarebbe più facile scrivere una traduzione riga per riga di un programma COBOL in PL / SQL rispetto, ad esempio, in Java.
Le stored procedure vengono eseguite nel server del database , quindi vengono eseguite più rapidamente di un codice client in Java in un server applicazioni o client.
Farai anche meglio senza il sovraccarico di DAO / JDBC, poiché la velocità è così critica.
Cosa c'è di meglio gestire in modo ottimale i blocchi e le transazioni quello stesso linguaggio specificamente incorporato nell'RDBMS per quello scopo.

Credo che il primo di questi quattro vantaggi sia quello più importante. E avrai un vantaggio aggiuntivo in quanto un esperto di business non di programmazione probabilmente comprenderà il codice e potrebbe aiutarti a convalidare le formule e le regole aziendali.

Ho fatto un buon numero di programmazione PL / SQL di Oracle per applicazioni critiche e posso dirti che è in grado di gestire transazioni enormi. Penso che sì, SP sia uno strumento adatto allo scopo .

score 3 · Answer 2

Direi 99 volte su 100 la risposta è stringere i denti e riutilizzare il codice COBOL esistente. Sembra che potrebbe avere una logica abbastanza complessa dietro le quinte; a meno che tu non abbia una specifica aggiornata e accurata potresti avere problemi a riprodurre la logica in tutte le sue sfumature. Questo è un male mojo su un'applicazione finanziaria in quanto i contatori di bean vorranno la compatibilità bug-per-bug con il codice legacy.

Quindi, come prima tappa, ti suggerirei di indagare seriamente su cosa è necessario per avvolgere il tuo processo precedente o integrarlo con il front-end. Si potrebbe dare un'occhiata alle opzioni di integrazione COBOL-Java disponibili da Micro Focus.

Se davvero non riesci a ripetere il ciclo del codice esistente, allora hai un problema significativo. Mentre uno sproc potrebbe fare ciò che si desidera, si ha il problema di creare qualcosa che riproduca l'esatto comportamento di un'applicazione COBOL apparentemente complessa e probabilmente scarsamente documentata.

A meno che il processo di sostituzione non sia radicalmente più lento, il wrapping di DML di 2000 in una transazione non sarà un grosso problema. È possibile avvolgere interi processi ETL in una transazione e ripristinarli in caso di errore. Ho visto un'applicazione in cui era necessario farlo, sebbene sia inusuale. La divisione di una transazione finanziaria è un no-no, specialmente su un sistema di doppia entrata. In quasi tutti i casi dovrebbe essere eseguito il commit o il rollback atomicamente. Segui la singola transazione.

Il fatto che l'applicazione COBOL computi un DML alla volta e utilizzi i risultati nel passaggio successivo del calcolo non è di buon auspicio per la conversione per impostare le operazioni. Preparati a farlo fila per fila e trova il modo di farlo correre velocemente. Una procedura memorizzata potrebbe essere il modo per farlo. Non dici cosa DBMS stai usando (DB / 2 per Z / OS?).

Inoltre, potrebbe essere necessario scendere alle transazioni XA (java.transactions API) e JDBC, soprattutto se è necessario lavorare nel livello client. Se vuoi ottenere buone prestazioni su operazioni basate su 2000 righe, potresti dover andare sotto il framework.