Il comportamento transazionale è mai necessario al di fuori dei database?

StackOverflow https://stackoverflow.com/questions/296909

Domanda

Non oserei fare nulla di complesso in un database senza transazioni. C'è quasi sempre un comando integrato semplice da usare. Ma quando inizi a lavorare con altri dati persistenti, non ottieni questo supporto per le transazioni semplice da usare. Alcuni esempi sono

  • file system
  • servizi web (nessuno che io abbia usato)

Anche nei dati non persistenti è spesso utile annullare un blocco di lavoro, a seguito di un'eccezione. Nessuna delle strutture di dati standard ottenute con una lingua, supporta le transazioni.

Quello che vorrei sapere è, perché i database sono il caso speciale?

Esistono collegamenti utili all'argomento del comportamento transazionale al di fuori dei database?

È stato utile?

Soluzione

Devo dissentire rispettosamente: i sistemi transazionali non sono automaticamente ed esclusivamente motori di database, al contrario ...

Ho implementato un meccanismo di transazione dell'applicazione (in .NET) che è distinto da una transazione di database. In realtà è piuttosto semplice (alcune ore di lavoro inclusa una suite di test unitari). È completamente scritto in C # senza dipendenze da alcuna funzionalità del database o qualsiasi altro componente. Ma prima un po 'di contesto ...

Questa funzione di transazione non di database esiste in diverse manifestazioni sulla piattaforma Java, come ad esempio EJB, ESB, JMS e spesso in associazione con BPM. Alcune di queste manifestazioni usano un database sottostante, ma non sempre e non per necessità. Altre piattaforme hanno manifestazioni comparabili, come MSMQ.

La maggior parte dei sistemi di controllo della versione legacy NON implementa la semantica delle transazioni ACID. Come diceva ddaa, CVS non lo fa, ma Subversion (il suo successore). Visual Source Safe no. Se cerchi Subversion, puoi trovare grafici comparativi che evidenziano questo punto.

Ora per il punto critico, una transazione di database o un suo equivalente non garantisce una logica aziendale sicura. Anche se adoro Subversion, ironicamente è un ottimo esempio di questo fatto.

È possibile utilizzare Subversion religiosamente, insieme a uno script di compilazione automatizzato (un comando che compila, testa e impacchetta l'applicazione) e continua a eseguire il commit di una build interrotta nel repository di controllo del codice sorgente. L'ho visto più volte. Naturalmente, è ancora più facile con strumenti di controllo del codice sorgente non basati su transazioni ACID come VSS. Ma è scioccante per molte persone apprendere che è possibile con strumenti come Subversion.

Mi permetta, per favore, di delineare lo scenario. Tu e un collega state sviluppando un'applicazione e utilizzate Subversion per il repository di controllo del codice sorgente. Entrambi state codificando e occasionalmente impegnate nel repository. Apportare alcune modifiche, eseguire una build pulita (ricompilare tutti i file di origine) e passare tutti i test. Quindi, impegni le tue modifiche e vai a casa. Il tuo collega ha lavorato sulle sue modifiche, quindi esegue anche una build pulita, vede passare tutti i test e si impegna nel repository. Ma il tuo collega si aggiorna dal repository, apporta alcune modifiche, esegue una build pulita e la build gli esplode in faccia! Ripristina le sue modifiche, aggiorna nuovamente dal repository (solo per essere sicuro) e scopre che una build pulita esplode ancora! Il tuo collega impiega le prossime due ore a risolvere i problemi relativi alla build e alla fonte e alla fine trova una modifica che hai fatto prima di partire che causa l'errore di compilazione. Ti lancia una brutta e-mail a te e al tuo capo comune, lamentando che hai rotto la build e poi con noncuranza sei tornato a casa. Arrivi al mattino per trovare il tuo collega e il tuo capo che aspettano alla tua scrivania per maledirti e tutti gli altri stanno guardando! Quindi esegui rapidamente una build pulita e mostri loro che la build non è stata interrotta (tutti i test passano, proprio come ieri sera).

Quindi, come è possibile? È possibile perché la workstation di ogni sviluppatore non fa parte della transazione ACID; Subversion garantisce solo i contenuti del repository. Quando il collega si è aggiornato dal repository, la sua stazione di lavoro conteneva una copia mista dei contenuti del repository (comprese le modifiche) e le sue stesse modifiche non impegnate. Quando il tuo collega ha eseguito una build pulita sulla sua workstation, stava invocando una transazione commerciale NON protetta dalla semantica ACID. Quando ha annullato le modifiche ed eseguito un aggiornamento, la sua stazione di lavoro ha quindi abbinato il repository ma la build era ancora al verde. Perché? Perché anche la tua workstation faceva parte di una transazione commerciale separata che NON era protetta dalla semantica ACID, diversamente dal tuo impegno con il repository. Dato che non hai aggiornato la tua workstation in modo che corrisponda al repository prima di eseguirti

Altri suggerimenti

Penso che il motivo per cui le transazioni sono viste solo nei database sia che, per definizione, i sistemi che forniscono transazioni sono chiamati database. Sembra circolare, quindi devo elaborare.

Il supporto per le transazioni è la funzione che fornisce le proprietà ACID . In parole povere, ciò significa che una transazione è qualcosa che consente di: 1. raggruppare una serie di operazioni discrete in un pacchetto che ha esito positivo nel suo insieme o fallisce nel suo insieme 2. nascondere le modifiche non confermate agli utenti simultanei, in modo che 3. utenti simultanei avere sempre una "costante" vista del sistema.

Filesystem offre tradizionalmente un meccanismo di blocco, ma questo è diverso dal fornire transazioni. Tuttavia, tutti i filesystem hanno alcune proprietà atomiche. Ad esempio, se si dispone di directory / a / e / b / e si tenta contemporaneamente di eseguire mv / a / b / a e mv / b / a / b , solo una di queste operazioni avrà esito positivo, senza compromettere l'integrità. Ciò che generalmente manca ai filesystem è la capacità di raggruppare più operazioni in un unico pacchetto atomico.

Una risposta menzionato Subversion. Tutti i sistemi di controllo della versione sana hanno transazioni. Quando si esegue il commit su più file, il sistema applica completamente il commit o lo rifiuta completamente (tranne CVS, che non considero sano). La causa del rifiuto è sempre un cambiamento simultaneo. Gli implementatori del sistema di controllo della versione sono molto consapevoli del mantenimento di un database.

Un'altra risponde citando i sistemi di messaggistica come transazionali . Non ho letto il materiale collegato, ma la risposta stessa ha menzionato solo la consegna atomica di messaggi. Non si tratta di transazioni.

Non ho mai sentito parlare di Clojure prima di Brian C. lo ha menzionato qui. Mi sembra davvero un'implementazione di transazioni al di fuori del contesto di un database. Qui il focus è il controllo della concorrenza, piuttosto che mantenere la coerenza di dati durevoli.

Quindi, ad eccezione di Clojure, sembra che qualsiasi sistema che necessita di transazioni utilizzi un database sottostante o si trasformi in un database.

I file system moderni hanno transazioni. Sono solo trasparenti per l'utente finale.

NTFS, XFS, JFS, EXT3 e ReiserFS fanno tutti, solo per citarne alcuni.

E questo è solo interno al file system. Molti sistemi operativi supportano anche il blocco dei file (vedi flock (2) nel mondo * NIX, ad esempio) con blocchi esclusivi (scrittura) e condivisi (lettura).

Modifica: Se ci pensate, i file system non hanno livelli di isolamento come i moderni DB perché una volta terminata la lettura di un file, tradizionalmente lo chiudete se non lo bloccate. Quindi lo riapri quando vuoi scrivergli.

Clojure utilizza Memoria transazionale software , che utilizza le transazioni per rendere semplice e sicuro la scrittura di programmi multi-thread senza blocchi manuali. Clojure ha strutture di dati immutabili con riferimenti mutabili e sono necessarie transazioni per modificare i riferimenti.

I sistemi di messaggistica sono un altro esempio di gestori di risorse transazionali.

Cioè, puoi assicurarti che un consumatore di messaggi elabori correttamente un messaggio dalla coda. Se l'elaborazione non riesce, il messaggio viene lasciato nella coda.

Inoltre, un sistema di messaggistica può prendere parte a una transazione distribuita con un altro gestore risorse.

Maggiori informazioni su

I commit di Subversion sono transazionali: sono veramente atomici, quindi un commit interrotto non lascia il repository in uno stato incoerente.

Ho avuto la situazione di cui avevo bisogno per trattare un filesystem e un database come un'unità transazionale.

Nel mio caso avevo solo bisogno di scaricare un set di file nel filesystem. L'ho fatto creando directory casuali ogni volta, inserendo i dati lì e memorizzando il nome della directory in una tabella di database. Pertanto, tutto il mio lavoro sul database e il nome della directory nella tabella del database (= lavoro sul filesystem) potrebbero essere eseguiti in una transazione del database.

http://www.databaseandlife.com/atomic-operations -over-file system e database /

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top