Oracle
 sql >> Database >  >> RDS >> Oracle

Oracle è in ritardo tra commit e select

Per impostazione predefinita, il comportamento che hai descritto dovrebbe essere impossibile:le modifiche apportate in una transazione confermata diventano immediatamente disponibili per tutte le sessioni. Tuttavia, ci sono delle eccezioni:

  1. Stai usando una delle opzioni SCRITTURA nel comando COMMIT? In caso contrario, conferma il valore del tuo parametro di inizializzazione COMMIT_WRITE. Se uno dei due utilizza "SCRIVI BATCH" o in particolare "SCRIVI BATCH ORA", potresti aprirti a problemi di concorrenza. "WRITE BATCH NOWAIT" verrebbe in genere utilizzato nei casi in cui la velocità delle transazioni di scrittura è di maggiore importanza rispetto a possibili problemi di concorrenza. Se il tuo parametro di inizializzazione utilizza le varianti "WRITE", puoi sovrascriverlo su base transazionale specificando la clausola IMMEDIATE nei tuoi commit (vedi COMMIT)

  2. La transazione che sta tentando di leggere i dati invoca SET TRANSACTION prima che l'altra transazione si impegni? L'utilizzo di SET TRANSACTION per specificare SERIALIZATION LEVEL READ ONLY o SERIALIZABLE comporterà che la transazione non vedrà modifiche che si verificano da altre sessioni impegnate che si sono verificate dopo l'invocazione di SET TRANSACTION (vedi SET TRANSACTION)

modifica:vedo che stai usando una classe DataSource. Non ho familiarità con questa classe:presumo che sia una risorsa di condivisione della connessione. Mi rendo conto che l'attuale progettazione dell'app potrebbe non semplificare l'utilizzo dello stesso oggetto di connessione durante il flusso di lavoro (i passaggi potrebbero essere progettati per funzionare in modo indipendente e non hai creato una struttura per passare un oggetto di connessione da un passaggio al successivo), ma è necessario verificare che gli oggetti di connessione restituiti all'oggetto DataSource siano "puliti", soprattutto per quanto riguarda le transazioni aperte. È possibile che tu non stia richiamando SET TRANSACTION nel tuo codice, ma un altro consumer di DataSource potrebbe farlo altrove e restituire la connessione all'origine dati con la sessione ancora in modalità SERIALIZABLE o READ ONLY. Quando si condivide la connessione, è fondamentale che tutte le connessioni vengano ripristinate prima di passarle a un nuovo consumatore.

Se non hai il controllo o la visibilità sul comportamento della classe DataSource, potresti provare a eseguire un ROLLBACK sulla connessione appena acquisita per assicurarti che non abbia già stabilito una transazione persistente.