Come per tutte le cose relative alle prestazioni, la risposta è:dipende. In particolare, dipende esattamente da come stai usando il driver.
Il costo dell'interazione transazionale con un database è suddiviso grosso modo in:sovraccarico di complessità del codice, sovraccarico di comunicazione, elaborazione sql e I/O del disco.
Il sovraccarico di comunicazione differisce leggermente tra i casi XA e non XA. A parità di condizioni, una transazione XA comporta un po' più di costo in quanto richiede più round trip al db. Per una transazione non XA in modalità commit manuale, il costo è di almeno due chiamate:le operazioni sql e il commit. Nel caso XA è inizio, operazioni sql, fine, preparazione e commit. Per il tuo caso d'uso specifico che ottimizzerà automaticamente l'avvio, le operazioni sql, la fine, la preparazione. Non tutte le chiamate hanno lo stesso costo:i dati spostati nel set di risultati di solito prevarranno. Su una LAN il costo dei viaggi di andata e ritorno aggiuntivi non è generalmente significativo.
Si noti tuttavia che ci sono alcuni trucchi interessanti in agguato in agguato per gli incauti. Ad esempio, alcuni driver non supportano la memorizzazione nella cache delle istruzioni preparate in modalità XA, il che significa che l'utilizzo di XA comporta il sovraccarico aggiuntivo della rianalisi dell'SQL a ogni chiamata o richiede l'uso di un pool di istruzioni separato sopra il driver. Mentre sull'argomento dei pool, il pool corretto delle connessioni XA è un po' più complesso rispetto al pool di quelle non XA, quindi, a seconda dell'implementazione del pool di connessioni, potresti vedere anche un leggero problema. Alcuni framework ORM sono particolarmente vulnerabili al sovraccarico del pool di connessioni se utilizzano un rilascio di connessione aggressivo e riacquisiscono nell'ambito della transazione. Se possibile, configura per acquisire e mantenere una connessione per tutta la vita del tx invece di colpire il pool più volte.
Con l'avvertenza menzionata in precedenza in merito alla memorizzazione nella cache delle istruzioni preparate, non vi è alcuna differenza sostanziale nel costo della gestione di sql tra XA e tx non XA. C'è tuttavia una piccola differenza nell'utilizzo delle risorse sul server db:in alcuni casi potrebbe essere possibile che il server rilasci le risorse prima nel caso non XA. Tuttavia, le transazioni sono normalmente abbastanza brevi da non essere una considerazione significativa.
Ora consideriamo l'overhead di I/O del disco. Qui ci occupiamo dell'I/O causato dal protocollo XA piuttosto che dell'SQL utilizzato per la logica aziendale, poiché quest'ultima è invariata in entrambi i casi. Per le transazioni di sola lettura la situazione è semplice:un sensato gestore db e tx non eseguirà scritture di log, quindi non c'è sovraccarico. Per i casi di scrittura lo stesso vale quando il db è l'unica risorsa coinvolta, a causa dell'ottimizzazione del commit in una fase di XA. Per il caso 2PC ogni server db o altro gestore risorse necessita di due scritture su disco invece di quella utilizzata nei casi non XA, e anche il gestore tx ne ha bisogno due. Grazie alla lentezza dell'archiviazione su disco, questa è la principale fonte di sovraccarico delle prestazioni in XA rispetto a non XA.
Diversi paragrafi fa ho menzionato la complessità del codice. XA richiede un'esecuzione di codice leggermente maggiore rispetto a non XA. Nella maggior parte dei casi la complessità è sepolta nel gestore delle transazioni, anche se ovviamente puoi guidare XA direttamente se preferisci. Il costo è per lo più banale, fatte salve le avvertenze già citate. A meno che tu non stia utilizzando un gestore delle transazioni particolarmente scadente, nel qual caso potresti avere un problema. Il caso di sola lettura è particolarmente interessante:i fornitori di gestori di transazioni di solito dedicano i loro sforzi di ottimizzazione al codice I/O del disco, mentre la contesa di blocco è un problema più significativo per i casi d'uso di sola lettura, in particolare su sistemi altamente simultanei.
Si noti inoltre che la complessità del codice nel gestore tx è una specie di falsa pista nelle architetture che includono un server app o un altro provider di gestione delle transazioni standard, poiché di solito utilizzano più o meno lo stesso codice per il coordinamento delle transazioni XA e non XA. Nei casi non XA, per perdere completamente il gestore tx, in genere devi dire al server / framework dell'app di considerare la connessione come non transazionale e quindi guidare il commit direttamente utilizzando JDBC.
Quindi il riepilogo è:Il costo delle tue query sql dominerà il tempo di transazione di sola lettura indipendentemente dalla scelta XA/non XA , a meno che non si incasini qualcosa nella configurazione o si eseguano operazioni sql particolarmente banali in ogni tx, essendo quest'ultimo un segno che la vostra logica aziendale potrebbe probabilmente utilizzare alcune ristrutturazioni per modificare il rapporto tra l'overhead di gestione tx e la logica aziendale in ogni tx.
Per i casi di sola lettura si applica quindi il consueto consiglio agnostico del protocollo di transazione:considerare una cache di secondo livello di livello di rilevamento delle transazioni in una soluzione ORM piuttosto che colpire il DB ogni volta. In caso contrario, sintonizzare sql, quindi aumentare la cache del buffer del db fino a quando non si vede una percentuale di successo superiore al 90% o si esauriscono gli slot RAM del server, a seconda dell'evento che si verifica per primo. Preoccupati di XA e non-XA solo una volta che l'hai fatto e hai scoperto che le cose sono ancora troppo lente.
