Questa pagina riassume le specifiche via via fornite per le attività da svolgere
con il DBMS didattico SimpleDB
Nota generale
Il lavoro va sintetizzato in una relazione di alcune pagine (con allegati i test
e le principlai classi modificate),
che permetta di comprendere il lavoro svolto e i risultati ottenuti.
Installare il DBMS didattico SimpleDB.
Notare che nel materiale scaricabile è contenuto un file README.txt
che, pur breve, contiene tutte le informazioni necessarie
1. Attività proposte con gli esercizi di autovalutazione
dell'11/03/2011
(Aggiornato il 18/03/2011, con alcuni chiarimenti, correzioni e suggerimenti)
Effettuare le seguenti modifiche al codice:
Modificare la classe FileMgr in modo che supporti statistiche sul numero
di blocchi letti e/o scritti (aggiungere uno o più metodi allo scopo)
Modificare i metodi commit e rollback della classe
RemoteConnectionImplementation
(in simpledb.remote) in modo che stampino queste statistiche;
debbono accedere al FileMgr che può essere ottenuto con il
metodo SimpleDB.fileMgr (del package simpledb.server)
Modificare BufferMgr per contare le richieste di pin()
Modificare il Record Manager per contare i record che vengono
letti. Il record Manager è realizzato attraverso diverse classi.
Valutare quale deve essere modificata. Notare anche che gli oggetti
appartenti alle classi in questione vengono creati e distrutti
dinamicamente. Notare anche che il concetto di lettura di record può avere varie interpretazioni (riguardo ad esempio ai record inutilizzati).
Utilizzando SimpleDB (o meglio, i suoi moduli di livello più basso),
scrivere una classe di test che esegue alcune operazioni su un file.
Avvertenze:
porre la classe nel package simpledb.record
la classe deve disporre di alcuni degli oggetti del server;
allo scopo, includere una chiamata al metodo init di SimpleDB: SimpleDB.init("studentdb");
RecordFile fa riferimento ad una transazione, che
deve essere creata allo scopo: Transaction tx = new Transaction();
RecordFile fa riferimento allo schema logico e a quello
fisico della tabella che viene implementata;
vanno entrambi creati nella classe di test:
Schema sch = new Schema();
sch.addIntField(} ..... e/o sch.addStringField(...);
... (due o tre campi, non di più) TableInfo ti = new TableInfo("prova",sch);
Nella classe di test, effettuare
l'inserimento di una sequenza di 10000 record (con valori generati casualmente)
la stampa di tutti i record
l'eliminazione di una parte dei record (orientativamente il
50% dei record; ad esempio, quelli per cui il
valore di un campo soddisfa una certa condizione)
la scansione di tutti i record (con la lettura
di un campo numerico e un qualche calcolo,
ad esempio il valore medio)
l'inserimento di altri 7000 record (sempre con valori generati casualmente)
Per ciascuna delle operazioni, stampare il numero di record letti e scritti, il numero di richieste di
pin ricevute dal buffer e il numero di accessi a memoria secondaria.
Come illustrato brevemente a lezione, esistono varie strategie
utilizzabili da parte del gestore del buffer per scegliere la pagina da utilizzare (e quindi il blocco da rimpiazzare) per eseguire una
pin (o fix):
naif: se ne sceglie una qualunque
FIFO: si sceglie quella caricata da più tempo
LRU (least recently used): si sceglie quella
utilizzata meno di recente
clock: si sceglie la prima libera successiva
a quella utilizzata in occasione dell'ultimo rimpiazzo;
questa strategia considera il buffer come circolare
(la prima pagina è successiva all'ultima) e da ciò deriva il nome.
Il gestore del buffer di SimpleDB utilizza la strategia naif
(il metodo chooseUnpinnedBuffer() nella classe BasicBufferMgr itera
sul buffer partendo sempre dall'inizio).
Implementare le altre tre strategie, modificando il metodo chooseUnpinnedBuffer().
2. Attività proposta con gli esercizi di autovalutazione
del 25/03/2011
SimpleDB, nella versione disponibile, effettua il checkpoint solo in fase di recovery.
Modificare il codice in modo che venga effettuato un checkpoint quiescente periodico
(ad esempio ogni N transazioni oppure circa ogni t secondi). Suggerimenti:
realizzare l'operazione attraverso un metodo statico nella classe
Transaction e stabilire come viene invocato
introdurre una variabile statica in Transaction che mantenga traccia
delle transazioni attive
modificare il costruttore di Transaction, in modo che la transazione sia
posta in attesa se è in corso un checkpoint
3. Attività proposte con gli esercizi di autovalutazione
del 01/04/2011
Sperimentare e arricchire il gestore della concorrenza di
SimpleDB nel modo seguente:
Realizzare una classe di test che confermi la corretta esecuzione
concorrente di transazioni che leggono e scrivono, ad esempio gestendo
uno schedule come il seguente:
scrivere la classe nel package tx e utilizzare un thread per
ciascuna transazione, introducendo pause forzate (con chiamate a
Thread.sleep() con opportuno parametro temporale)
realizzare le letture e le scritture con chiamate ai metodi
pin(), getInt() e setInt() su blocchi creati allo scopo
utilizzare l'eccezione InterruptedException
un esempio di classe,
più semplice di quella richiesta, con le varie
funzionalità
Realizzare un'altra classe di test che mostri il fatto che
può manifestarsi lo stallo. Mostrare anche che,
in tal caso, i lock delle trasnsazioni abortite rimangono assegnati,
impedendo così l'utilizzo degli oggetti coinvolti nello
stallo.
Modificare il gestore della concorrenza, per far
sì che, dopo lo scadere del timeout, le transazioni
abortite rilascino i lock.