Che materia stai cercando?

Basi di dati II - gli approcci MVCC Appunti scolastici Premium

Appunti di Basi di dati II per l'esame del professor Sansone. Glia rgomenti trattati sono i seguenti: gli approcci MVCC ed in particolare sull'approccio ottimistico (nessun controllo di concorrenza) 2PLMVCC e valutazione delle condizioni.

Esame di Basi di Dati II docente Prof. L. Sansone

Anteprima

ESTRATTO DOCUMENTO

2PL-MVCC

Serve a fare in modo, così come negli altri approcci MVCC, che le letture siano sempre soddisfatte.

L’idea è questa: per ogni oggetto X della base di dati vengono tenute 2 copie:

 X1: l’ultima copia modificata dopo un successful commit.

 X2: una copia in fase di modifica

Viene inoltre aggiunto un terzo tipo di lock, il certify lock.

Tutte le transazioni che vogliono solo leggere accedono in concorrenza agli oggetti X1, invece una

transazione T che vuole scrivere avrà una copia degli oggetti interessati, X2, su cui potrà apportare

le sue modifiche anche se ci sono transazioni che stanno leggendo proprio quei dati (la scrittura

invece è sempre esclusiva).

Quando T è pronta ad effettuare il commit deve ottenere un certify lock su ogni oggetto X che ha

modificato (quindi su cui detiene un write lock), siccome il certify lock è esclusivo rispetto a tutti gli

altri lock sarà necessario che ogni transazione bloccata in lettura su X1 rilasci il read lock prima

che T possa effettuare il commit.

Dopo il commit X1 verrà aggiornato alla versione modificata.

Approccio ottimistico

Nei sistemi in cui vi sono molte letture e relativamente poche scritture, approcci incentrati sul lock

come quelli visti aggiungono un bel po’ di overhead, che nella maggioranza dei casi potrebbe

essere evitato.

Gli approcci ottimistici, come suggerisce il nome, partono dal presupposto che “andrà tutto bene” e

quindi non applicano nessun controllo di concorrenza, salvo verificare alla fine se la modifica può

essere accettata: in questo modo le transazioni sono servite alla massima velocità possibile.

Funziona così: si prevedono 3 fasi:

 Reading phase: lettura degli oggetti X ed eventuale modifica, effettuata però su copie

locali a ciascuna transazione.

 Validation phase: in questa fase ogni transazione sottomette le modifiche fatte e queste

devono essere validate.

 effettiva scrittura della modifica oppure all’abort della

Write phase: si procede alla

transazione se non si è passata la fase precedente.

A supporto del metodo a ogni transazione è associato un timestamp, inoltre per ogni fase vengono

mantenuti i tempi di inizio e fine, nonché una lista degli oggetti letti (read set) e modificati (write

set).

La fase di validazione si divide a sua volta in 3 fasi, dalla meno complessa alla più onerosa, e

basta che una qualsiasi di queste sia soddisfatta per essere sicuri che la transazione non

interferirà con le altre (quindi una transazione andrà in abort solo se falliscono tutte e tre).

Questo vuol dire che nel caso migliore basterà verificare solo la più semplice (e rapida!) per far

passare una transazione. Vediamo ora nel dettaglio le 3 fasi:


PAGINE

2

PESO

181.13 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Basi di Dati II e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Sansone Lucio.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Basi di dati ii

Sicurezza delle basi di dati
Appunto
Basi di Dati II - DB Spaziali
Dispensa
Teoria completa, Metodi Matematici per l'Ingegneria
Appunto
Geometria e Algebra - Determinanti
Dispensa