Objectivity in CMS

Objectivity e' parte di LHC++ cioe' del software raccomandato per gli esperimenti LHC. Esso e' stato adottato da CMS.Comunque,un certo numero di problemi vanno risolti riguardo il suo uso.

Quante risorse richiede?Quanto e' facile installarlo.
Che problemi comporta il rilascio di una nuova versione?
Quanti utenti riescono ad accedere nello stesso momento?
Quante risorse richiede un programma che acceda ai dati di Objectivity?
Cosa succede se un utente richiede di accedere a tutti i dati (stripping)
Quali alternative abbiamo? ROOT e' un'alternativa possibile?

Per quanto riguarda CMS , Objectivity e' disponibile sulla Sun dell'esperimento e per quelli che vogliono fare delle prove esistono degli esercizi su

  /afs/cern.ch/sw/lhcxx/share/OBJYtraining/

con la documentazione e i sorgenti.
Questo e' invece la documentazione ufficiale del Cern
L'uso di Objectivity su macchine Unix richiede il seguente codice nel .login.

setenv OBJY_VERS 5.1
if (-r /afs/cern.ch/rd45/objectivity/objyenv.csh) then
source /afs/cern.ch/rd45/objectivity/objyenv.csh
endif

La nomeclatura

Objectivity permette di memorizzare oggetti persistenti il cui schema(modello di dati) e' definito sia in C++ o in Java usando delle classi che estendono o implementano una particolare interfaccia.La definizione stessa di queste classi e' fatta usando un Data Definition Language(DDL).Questa operazione nel gergo dei database viene chiamata definizione dello schema e consiste nella creazione di speciali files con suffisso ddl.In questi files vengono definite le classi persistenti.Gli oggetti persistenti sono memorizzati nei database organizzati in container.Di solito ogni database e' un file ed ha un unico ID DBID number che lo identifica. Piu' database formano una federation o federated database rappresentata da un Federated Database File.Questo file ha il suffisso

FDDB e risiede sul server dei cataloghi. Esso contiene lo schema e il catalogo dei database federati.Anche le federazioni hanno un unico FDID.
Infine il Boot File descrive le federazioni disponibili e la locazione
del lock server ed e' l'unico file che deve essere visibile dall'esterno
all'utente.L'accesso al database da parte di un'applicazione su un computer
remoto richiede la presenza di un demone AMS (Advanced Multi-threaded Server).Il lock server gira su un altro computer ed ha il solo scopo 
di evitare che piu' applicazioni possano rovinare i dati manipolandoli nello
stesso momento. Un'applicazione puo' richiedere un  read  o update
lock. Piu' applicazioni possono girare con read lock, solo una con update lock.
Il read lock e' incompatibile con l'update lock.Il lock viene richiesto per
la durata di un'operazione detta in gergo transazione.

 Alcuni comandi usati per operare sul database via finestra telnet o MS/DOS:

ools - per far partire il lock server
oocheckls - per controllare se il lockserver e' in funzione
ootoolmgr - per far partire il tool manager


Giuseppe Zito
 
Last modified: