Quali sono i problemi legati all'utilizzo delle transazioni in un database?

Question

Da questo post.Un problema ovvio è la scalabilità/prestazioni.Quali sono gli altri problemi che provocheranno le transazioni?

Potresti dire che ci sono due serie di problemi, uno per le transazioni a lungo termine e uno per quelle a breve termine?Se sì, come li definiresti?

MODIFICARE:Il deadlock è un altro problema, ma l'incoerenza dei dati potrebbe essere peggiore, a seconda del dominio dell'applicazione.Supponendo un dominio degno di transazione (bancario, per usare l'esempio canonico), la possibilità di stallo è più simile a un costo da pagare per garantire la coerenza dei dati, piuttosto che a un problema con l'utilizzo delle transazioni, o non saresti d'accordo?In tal caso, quali altre soluzioni utilizzeresti per garantire la coerenza dei dati senza situazioni di stallo?

Answer 1

Dipende molto dall'implementazione transazionale all'interno del database e può anche dipendere dal livello di isolamento delle transazioni utilizzato.Presumo "lettura ripetibile" o superiore qui.Mantenere aperte le transazioni per un lungo periodo (anche quelle che non hanno modificato nulla) costringe il database a trattenere righe cancellate o aggiornate di tabelle che cambiano frequentemente (nel caso in cui si decida di leggerle) che altrimenti potrebbero essere gettate via.

Inoltre, il rollback delle transazioni può essere molto costoso.So che nel motore InnoDB di MySQL, il rollback di una grande transazione può richiedere MOLTO più tempo rispetto al commit (abbiamo visto un rollback richiedere 30 minuti).

Un altro problema ha a che fare con lo stato di connessione al database.In un'applicazione distribuita e tollerante agli errori, non puoi mai sapere veramente in quale stato si trova una connessione al database.Le connessioni al database con stato non possono essere mantenute facilmente poiché potrebbero fallire in qualsiasi momento (l'applicazione deve ricordare cosa si trovava nel mezzo dell'operazione e rifarla).Quelli senza stato possono semplicemente essere ricollegati e riemettere il comando (atomico) senza (nella maggior parte dei casi) interrompere lo stato.

Answer 2

Puoi ottenere deadlock anche senza utilizzare transazioni esplicite.Per prima cosa, la maggior parte dei database relazionali applicherà una transazione implicita a ogni istruzione eseguita.

I deadlock sono fondamentalmente causati dall'acquisizione di più lock e qualsiasi attività che implica l'acquisizione di più di un lock può bloccarsi con qualsiasi altra attività che implica l'acquisizione di almeno due lock uguali alla prima attività.In una transazione di database, alcuni dei blocchi acquisiti potrebbero essere mantenuti più a lungo di quanto verrebbero altrimenti mantenuti, fino alla fine della transazione, di fatto.Più a lungo vengono mantenuti i lock, maggiore è la possibilità che si verifichi una situazione di stallo.Questo è il motivo per cui una transazione di lunga durata ha maggiori possibilità di stallo rispetto a una di breve durata.

Answer 3

Un problema con le transazioni è che è possibile (improbabile, ma possibile) ottenere deadlock nel DB.Devi capire come funziona il tuo database, come si blocca, come effettua le transazioni, ecc. per eseguire il debug di questi problemi interessanti/frustranti.

-Adamo

Answer 4

Penso che il problema principale sia a livello di design.A quale livello o livelli all'interno della mia applicazione utilizzo le transazioni.

Ad esempio potrei:

• Creare transazioni all'interno di procedure memorizzate,
• Utilizza l'API di accesso ai dati (ADO.NET) per controllare le transazioni
• Utilizzare una qualche forma di rollback implicito più in alto nell'applicazione
• Una transazione distribuita in (tramite DTC/COM+).

L'utilizzo di più di uno di questi livelli nella stessa applicazione spesso sembra creare problemi di prestazioni e/o di integrità dei dati.