L'utilizzo di 'Commit Retaining' compromette le prestazioni di Firebird?

Question

Gli estratti qui riportati sembrano contraddittori su questo punto.

(Sono entrambi piuttosto vecchio credo, la seconda è a partire dal 2004 e la prima menziona Borland così deve essere vecchio e, in modo forse non sono aggiornati.)

Il primo sembra suggerire che commettono conservando mantiene attiva la transazione e quindi attaccherà l'OIT.

Il secondo, se capisco, implica che con un mantenimento del commit, il TID esistente viene contrassegnato come commit e la transazione viene mantenuta attiva ma con un nuovo TID e quindi non si attacca l'OIT. Questo secondo estratto riguarda Interbase, non so se questo spieghi l'apparente contraddizione.

Firebird Documentation Estratto:

Con Firebird (e InterBase), Commit Mantenere le transazioni induce a rimangono interessanti a tempo indeterminato. La garbage collection cessa di fatto sull'applicazione di database di strumenti RAD Borland "standard" e qualsiasi altra applicazione che utilizza Commit Retaining.

Embarcadero Blog post estratto

Leggi commesso, lettura-scrittura:

Questa transazione può essere eseguito per sempre senza alcun impatto negativo sulle prestazioni se si fa un commit mantenere di volta in volta.

Answer 1

Quando si utilizza commettere mantenendo (o utilizzando l'API o con COMMIT RETAIN) con Firebird, la transazione avviata non è realmente finita, diventerà sempre associata con l'insieme delle transazioni visibili da una nuova transazione che è stato avviato internamente , pur mantenendo attivo il vecchio (i).

Ciò significa che le transazioni meno recenti più interessanti e più vecchie attive non si spostano e che le versioni precedenti si accumulano che non possono essere raccolte automaticamente finché la transazione non viene realmente impegnata. Ciò significa che alla fine le query dovranno eseguire la scansione di una catena più lunga di versioni dei record, che può avere un impatto sulle prestazioni.

Suppongo che ci siano alcune ottimizzazioni possibili, ad esempio la transazione originale potrebbe essere contrassegnata come commit se non ci sono cursori aperti che sono stati avviati nella transazione (una delle caratteristiche del mantenimento del commit è che i cursori non sono chiusi sul commit della transazione, che - se non sbaglio - richiede che il vecchio contesto della transazione rimanga disponibile). Questo potrebbe essere qualcosa che InterBase ha fatto per le transazioni read commit.

Questo può essere visto da solo avviando una sessione isql e facendo alcuni inserimenti in combinazione con il mantenimento del commit: se si controlla gstat -h in combinazione, si noterà che le transazioni più interessanti e meno recenti attive non si spostano fino a quando non si commettere.