Esecuzione del commit e del rollback delle transazioni
Per eseguire il commit o il rollback di una transazione in modalità commit manuale, un'applicazione chiama SQLEndTran. I driver per i DBMS che supportano le transazioni in genere implementano questa funzione eseguendo un'istruzione COMMIT o ROLLBACK. Gestione driver non chiama SQLEndTran quando la connessione è in modalità commit automatico. Restituisce semplicemente SQL_SUCCESS, anche se l'applicazione tenta di eseguire il rollback della transazione. Poiché i driver per i DBMS che non supportano le transazioni sono sempre in modalità commit automatico, possono implementare SQLEndTran per restituire SQL_SUCCESS senza eseguire alcuna operazione o non implementarlo affatto.
Nota
Le applicazioni non devono eseguire il commit o il rollback delle transazioni eseguendo istruzioni COMMIT o ROLLBACK con SQLExecute o SQLExecDirect. Gli effetti di questa operazione non sono definiti. Tra i possibili problemi, c’è il fatto che il driver che non sa più quando una transazione è attiva e il fatto che queste istruzioni hanno esito negativo rispetto alle origini dati che non supportano le transazioni. Queste applicazioni devono invece chiamare SQLEndTran.
Se un'applicazione passa l'handle di ambiente a SQLEndTran ma non passa un handle di connessione, Gestione driver chiama concettualmente SQLEndTran con l'handle di ambiente per ogni driver con una o più connessioni attive nell'ambiente. Il driver esegue quindi il commit delle transazioni su ogni connessione nell'ambiente. Tuttavia, è importante capire che né il driver né Gestione driver usano un protocollo 2PC sulle connessioni nell'ambiente; si tratta semplicemente della praticità di programmazione di chiamare contemporaneamente SQLEndTran per tutte le connessioni nell'ambiente.
Un protocollo 2PC viene in genere usato per eseguire il commit di transazioni distribuite su più origini dati. Nella prima fase viene eseguito il polling delle origini dati per stabilire se è possibile eseguire il commit della parte della transazione. Nella seconda fase, la transazione viene effettivamente sottoposta a commit in tutte le origini dati. Se le origini dati nella prima fase rispondono che non possono eseguire il commit della transazione, la seconda fase non si verifica.