Qual è la relazione tra livello di blocco, blocco e isolamento?

Question

Capisco un po 'di Oracle blocco - come aggiornamenti bloccano altri aggiornamenti fino al completamento della transazione, come gli scrittori non bloccano i lettori ecc

Capisco il concetto di blocco pessimistico e optimisic, e le tipiche esempi da manuale bancario circa perdere gli aggiornamenti persi ecc

capisco anche i livelli di isolamento delle transazioni JDBC in cui potremmo dire, per esempio, siamo felici di vedere i dati non impegnati.

Sono un po 'confusa ma di come questi concetti sono correlati e interagiscono. Per esempio:

• è Oracle fornendo blocco ottimistico pessimista o di default (è sembra solo per bloccare il aggiornamento separato sulla base di esperimenti in due sessioni rospo.)
• Se, come sospetto, questi sono concetti a livello di applicazione, perché avrei vado alla difficoltà di attuazione di una strategia di blocco quando posso lasciare che l'operazione di sincronizzazione banca dati aggiornamenti comunque?
• Come i livelli di isolamento della transazione (che ho impostato sulla connessione) alterano il comportamento del database quando altri client oltre alla mia applicazione accedono a diversi livelli di isolamento.

Qualsiasi parola per chiarire questi argomenti sarebbe molto apprezzata!

Answer 1

• Oracle consente entrambi i tipi di blocco: il modo in cui si costruisce l'app determina il tipo di utilizzo. In retrospettiva, non è davvero una decisione del database.

• Per lo più, chiusura di Oracle è sufficiente una connessione stateful al database. Nelle app non stateful, ad esempio le app Web, non è possibile utilizzarle. È necessario utilizzare il blocco a livello di applicazione in tali situazioni poiché il blocco si applica a una sessione.

• Di solito non c'è bisogno di preoccuparsi. In Oracle, i lettori non bloccano mai gli scrittori e gli scrittori non bloccano mai i lettori. Il comportamento di Oracle non cambia con i vari livelli di isolamento ANSI. Ad esempio, non esiste una "lettura sporca" in Oracle. Tom Kyte sottolinea che lo spirito di consentire letture sporche è quello di evitare il blocco delle letture, che non è un problema in Oracle.

che vi consiglio vivamente la lettura eccellente libro di Tom Kyte "Expert Oracle Database Architecture", in cui questi e altri temi sono affrontati abbastanza chiaramente.

Answer 2

Blocco ottimistico è fondamentalmente "Io chiudo solo i dati quando modifico i dati, non quando l'ho letto". Il trucco è che se non blocchi i dati subito, qualcun altro può cambiarlo prima di te e stai guardando le vecchie notizie (e può ciecamente sovrascrivere le modifiche che sono avvenute tra quando hai letto i dati e l'hai aggiornato.)

blocco pessimistico sta chiudendo i dati quando lo si legge in modo che sarete sicuri che nessuno è cambiato, se si decide di aggiornarlo.

Questa è una decisione di applicazione, non una decisione Oracle come:

x SELECT, y, z FROM tabella1 dove A = 2

non blocca i record corrispondenti ma

x SELECT y, z FROM table1 WHERE a = 2 PER AGGIORNAMENTO

will. Quindi, si deve decidere se sei ok con il blocco ottimistico

SELECT x, y, z FROM table1 WHERE a = 2 

... il tempo passa ...

UPDATE table1 
    SET x = 1, y = 2, z = 3 
WHERE a = 2 

(si potrebbe avere sovrascritto un cambiamento qualcun altro ha fatto nel frattempo)

o hanno bisogno di essere pessimisti:

SELECT x, y, z FROM table1 WHERE a = 2 FOR UPDATE 

... il tempo passa ...

UPDATE table1 
    SET x = 1, y = 2, z = 3 
WHERE a = 2 

(sei sicuro che nessuno ha cambiato i dati da quando interrogato esso.)

sezione sono riportati i livelli di isolamento disponibili in Oracle. http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/consist.htm#CNCPT621

Answer 3

Oracle SEMPRE gestisce il blocco pessimistico. Ovvero, bloccherà un record quando viene aggiornato (e puoi anche premere i blocchi per le eliminazioni e gli inserimenti se è coinvolta una chiave). È possibile utilizzare SELECT .... FOR UPDATE per aumentare la strategia di blocco pessimistica.

In realtà qualsiasi database/motore di archiviazione che funzioni a livello di transazione deve eseguire un qualche tipo di blocco.

Il livello di isolamento SERIALIZABLE è molto più vicino a un meccanismo di blocco ottimistico. Genera un'eccezione se la transazione tenta di aggiornare un record che è stato aggiornato dall'inizio della transazione. Tuttavia si basa su un one-to-one tra la sessione del database e la sessione dell'utente finale.

Poiché le applicazioni di pool di connessioni/apolidi diventano prevalenti, soprattutto nei sistemi con attività utente pesante, avere una sessione di database impegnata per un periodo prolungato può essere una strategia inadeguata. Il blocco ottimistico è preferito e le versioni successive di Oracle supportano questo con gli elementi ORA_ROWSCN e ROWDEPENDENCIES. Fondamentalmente rendono più facile vedere se un record è stato modificato da quando lo hai guardato inizialmente/l'ultimo.

Poiché la relazione uno a uno tra una sessione di database e una sessione utente è diventata legacy, il livello dell'applicazione ha conservato più dello stato di 'sessione utente' e quindi è diventato più responsabile del controllo delle scelte dell'utente fatti cinque/dieci minuti fa sono ancora validi (ad esempio il libro è ancora in magazzino o è stato acquistato da qualcun altro).