Strategie di chiusura alternative

Vorrei provare a risolverlo con (almeno) quattro stati del documento

• non lavorati
• esportazione avviata (ma non in elaborazione)
• in elaborazione (significa: al termine dell'esportazione)
• trattati

Inoltre, sarà probabilmente una buona idea aggiungere un campo data / ora per ricordare quando è stato modificato l'ultimo stato e, come sottolineato da @Bart, un campo aggiuntivo che l'utente ha causato il cambiamento di stato.

Lo stato cambia se stesso dovrebbe essere fatto per ogni singolo documento, in una singola, breve, transazione atomica. Ad esempio, prima dell'inizio dell'esportazione, impostare lo stato in modo appropriato. Dopo che l'esportazione è stata completata correttamente, si imposta anche lo stato di conseguenza. Quando il documento è stato elaborato, di nuovo. Ciò ti dà un controllo preciso sulle transazioni e consentirà il recupero dei singoli errori.

Ad esempio, supponendo che ci sia un'interruzione dell'alimentazione o un'interruzione della rete nel mezzo di un'esportazione di 100 documenti, questo vi lascerà con circa 50 documenti in "esportazione avviata" e 50 documenti "in elaborazione". Utilizzando il campo data / ora, è ora possibile rilevare facilmente quando ci sono documenti per i quali lo stato è ancora "esportazione avviata" per più di, diciamo, 15 minuti e reimpostare tali documenti su "non elaborato" dopo questo timeout. Puoi anche ripristinare i documenti da "in elaborazione" a non elaborati quando l'elaborazione richiede più di, diciamo, 5 giorni. Il controllo per questi stati in sospeso può essere fatto in un programma in background separato, in esecuzione, ad esempio, ogni minuto o ogni cinque minuti, qualunque sia la soluzione adatta al tuo processo.

In realtà, il "blocco di questi documenti" dovrebbe significare: tutti i documenti con stato diverso da "non elaborato" sono bloccati per esportazione e amp; elaborazione da altri - ma non utilizzando un "meccanismo di blocco del database" di lunga durata. Il database dovrebbe sempre rimanere reattivo e dirvi quanti documenti di quale stato sono memorizzati. A mio avviso, questa è ancora definita una strategia di "blocco pessimistico" (poiché lo stesso documento non deve essere elaborato da due utenti diversi contemporaneamente), ma con una strategia di failover.

Ci sono più gradazioni in "blocco" rispetto al puro pessimismo ("non consentire altri accessi di questo documento mentre viene guardato!") e puro ottimismo ("supponiamo che non ci siano accessi o aggiornamenti a questo documento sarà mai in conflitto tra loro! ").

1. C'è un blocco più granulare, ancora pessimistico. Ad esempio, consentire ai clienti di estrarre solo un documento alla volta. Questo è simile al "blocco a livello di riga" piuttosto che al "blocco tabella" nella progettazione DBMS.

2. Controllo della concorrenza a più versioni è ciò che la maggior parte dei moderni gestori di database utilizza al posto di ipotesi di blocco veramente pessimistiche. Può fornire le stesse proprietà ACID come blocco pessimistico tradizionale.

3. Concorrenti editor in tempo reale come Google Docs ed EtherPad consentono più aggiornamenti simultanei da più client a un modello di documento coerente. Sia il rialzo che il lato negativo è che non esiste una funzionalità di "checkout" e il coordinamento logico / semantico è responsabilità dei clienti.

4. I sistemi di controllo di revisione distribuiti come Git e Mercurial hanno una visione molto ottimistica e permissiva: tutti ottengono copie di tutto il documento che vogliono e può fare qualunque cambiamento vogliano. Quando in un secondo momento vogliono impegnare tali modifiche, l'ipotesi è che tutte le modifiche possano essere unite / re-integrate con successo nel master (e se ciò non può essere fatto con l'automazione completa, qualsiasi conflitto può essere automaticamente identificato e presentato a un umano per la selezione).

Ma piuttosto che una strategia di blocco, sembra che potresti aver bisogno di un programmatore di lavoro distribuito . Ogni ambiente HPC da tempo immemorabile ad oggi ha una qualche forma di pianificazione del lavoro, compresa la gestione degli errori per quando i processi muoiono o diventano AWOL. Pertanto, oltre alle strategie alternative per la gestione dei blocchi di documenti, valutare se questa funzionalità potrebbe essere più facilmente esternalizzata a un gestore lavoro.