Basi di dati II, primo modulo (ordinamento 270/2004)

Anno accademico 2009-2010

Progetto SimpleDB

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.

0. Attività preliminare (04/03/2011)

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)

1. Effettuare le seguenti modifiche al codice:
   1. Modificare la classe FileMgr in modo che supporti statistiche sul numero di blocchi letti e/o scritti (aggiungere uno o più metodi allo scopo)
   2. 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)
   3. Modificare BufferMgr per contare le richieste di pin()
   4. 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).
2. 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
   1. l'inserimento di una sequenza di 10000 record (con valori generati casualmente)
   2. la stampa di tutti i record
   3. 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)
   4. la scansione di tutti i record (con la lettura di un campo numerico e un qualche calcolo, ad esempio il valore medio)
   5. 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.
3. 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:

1. 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: r1(x), w2(y), w3(x), r1(y), c1, r2(x), c2, r3(y), c3 Suggerimenti:
   • 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à
2. 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.
3. Modificare il gestore della concorrenza, per far sì che, dopo lo scadere del timeout, le transazioni abortite rilascino i lock.