[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Objy/ROOT discussion at today's phone meeting
>
> This is what I understood of the usage of ROOT for MDC2:
>
> * Storage Manager will not be affected.
> * ROOT will contain some event components.
> * SM will provide Objy OID's and FID's and it's up to codes to find out
> what files to look for the events in. I.e., the codes will do the FID to
> ROOT file name mapping.
> * Objy's catalog for mapping of FID to filename will be used for ROOT
> files too.
>
> Comments?
> _________________________________________
> Henrik Nordberg <hnordberg@lbl.gov>
> Scientific Data Management Research Group
> Lawrence Berkeley National Laboratory
>
This is my understanding as well, with the clarification that the SM
will ALSO be a client of the FID-to-filename mapping, so that the
Cache Manager can deliver the correct files by the time the user code
tries to reach them.
I am not yet comfortable with the proposed approach to generating
FIDs for ROOT files, but Henrik's text does correctly describe the
current proposal. I have no objection to having Objectivity manage
the FID-to-name mapping; it's the consumption of Objectivity DB ids
(there are only 64K of them available--scalability implications?) and
faking Objectivity into believing that ROOT files are federation databases
(implications for database administration operations (install,
attach/detach, copy, ...?) that still bother me. (Some Objectivity tools
check whether an alleged database file is really an Objectivity database.)
There are certainly other ways to generate unique FIDs between ROOT and
Objectivity, as well as other ways to let Objectivity manage the mapping.
I realize that the proposed approach will probably be okay for MDC2.
Scalability, though, is the GCA's raison d'etre, so I am reluctant to
deceive Objectivity in a way that may diminish scalability unless there
is a good reason for it.
Can anyone allay my concerns? Does anyone else share them?
Cheers,
David