Come progettare un'applicazione con funzionalità di rollback

8

Attualmente sto lavorando su un'applicazione (fondamentalmente è una sorta di motore di esecuzione in grado di eseguire lavori definiti dall'utente e generare output in tempo reale) che deve gestire la funzionalità di rollback, potrebbe sembrare folle ma è possibile avere tale cosa a livello di applicazione? per esempio. immagina che un utente prova a eseguire un lavoro J1 e, una volta avviato, desidera modificarlo / modificarlo,

- ciò significa che il processo corrente in esecuzione deve essere ucciso,
- tutte le azioni intraprese finora devono essere ripristinate e
- rieseguire di nuovo il lavoro J1

poche cose che mi vengono in mente è che dobbiamo in qualche modo memorizzare o mantenere gli stati delle applicazioni in qualche modo, da qualche parte e poi chiamare il rollback insieme ai precedenti punti di salvataggio. Stavo leggendo alcuni articoli sul rollback a livello di DB ma lo scenario non si adatta in questo caso come ha bisogno di lavorare su un ambiente in tempo reale.

Ma non sono in grado di trovare un approccio corretto su come procedere e su quali altri aspetti dovrebbero essere presi in considerazione. Per favore fatemi sapere se questo non è chiaro, cercherò di fornire più informazioni se possibile.

Qualche aiuto o consiglio?

    
posta user2720864 23.12.2013 - 13:21
fonte

1 risposta

17

Sistema in tempo reale o no, memento pattern è un ottimo punto di partenza.

The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback).
The memento pattern is implemented with three objects: the originator, a caretaker and a memento.
The originator is some object that has an internal state.
The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do.
To roll back to the state before the operations, it returns the memento object to the originator.
The memento object itself is an opaque object (one which the caretaker cannot, or should not, change).
When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.

Ho suddiviso un po 'l'articolo di Wikipedia per focalizzare l'attenzione su alcuni elementi.

Per lo scenario, il mittente sarà il codice dell'applicazione principale, molto probabilmente nel punto in cui i lavori sono registrati e iniziano l'elaborazione.

Il custode è ciò che è necessario creare e potrebbe essere una sorta di sistema di registrazione o un altro archivio dati.

Il ricordo sarà le informazioni rilevanti che devono essere annullate e / o rifatte. Sospetto che questo assomigli ad una descrizione del lavoro di qualche tipo che possa essere ricollocata nella coda di elaborazione.

Se riesci a racchiudere le modifiche esistenti dal lavoro J1 con una transazione di database, questo si occuperà dei tuoi problemi di rollback ( all the action taken so far must be reverted ). Quando si verifica un rollback della transazione, si attiva una chiamata al gestore per ri-accodare il processo J1 .

Una cosa da tenere a mente è l'ultimo avviso nel riepilogo di Wikipedia. Devi assicurarti che le modifiche siano atomiche e che possano essere applicate o ripristinate come set coesivo.

Non sono sicuro che essere in un ambiente in tempo reale avrà un grande impatto su come implementare lo schema del ricordo. Se ci sono scadenze per le attività, allora potrebbe essere necessario profilare alcune delle modifiche per assicurarsi che il sistema risponda in un intervallo di tempo appropriato. Penso che implementerei prima la funzionalità e poi verificherò che soddisfi gli altri requisiti dell'applicazione. Non prevedo che ti imbatti in qualcosa che possa invalidare ciò che hai descritto finora.

    
risposta data 23.12.2013 - 17:22
fonte

Leggi altre domande sui tag