Re: Objectivity Question

["Torre Wenaus" <wenaus@bnl.gov>]

From: Shigeki Misawa <misawa@bnl.gov>

>
>Hello all.
>
>I've got an Objectivity question that hopefully someone can
>answer. (This might have been discussed previously, but I don't see a
>record of it.)
>
>During actual running of the experiment, I see at least 3 places where
>data bases will be created. The first is in the on-line systems where
>calibration/configuration data bases are being created. The second is
>in the DAQ system, where DB's are being created to index raw event
>data. The third is in the RCF reconstruction cluster where DB's
>containing reconstructed data are created.


In STAR the second (raw event indexing and TagDB) is actually in online. And a
fourth is RCF CAS where event components downstream of the DST (m/u/nDSTs) are
created and in some cases hung off the event. A fifth could be a home institute
building a nano-DST we want to send back to RCF and hang off the event.

>
>Presumably the data created in all three places will be accessed by
>analysis code at later stages of processing. This implies that all the
>data bases need to be in the same federation, or at least in
>federations with "compatible" schema.


For STAR, yup, in the same federation, same schema

>
>Is the assumption being made that there will be a single federation
>that will be accessible to all three systems that will be creating
>db's ?
>
>If yes, presumably FTO/DRO will be used and will "fix" any problems
>that may result from a breakdown in communication between the various
>partitions, yes ?
>
>Assuming that the above is the plan, if there is a breakdown in
>communication between RCF and the experiment, AFAIK, it appears that
>the reconstruction process proceeds to stop, since the DAQ/On-line
>systems will constitute the quorum. Am I missing something here ?


Again for STAR, no plan to use FTO/DRO (in the beginning) because of the quorum
problem. Instead use database copying between a 'satellite' federation in online
(or at a home institute) and the 'real' FDB in RCF.

>
>Along the same vein, I thought that having 3 separate federations
>would solve this problem, and that I would use oocopydb and ooattachdb
>to transfer db's between federation's. But this doesn't work since the
>db OID is cast in stone. Is this "fixed" in Version 5 ?
>


This better work! If I interpret Dave's message right, it will work.

>
>Documents from BaBar mention this problem, although the doc is dated
>Sept '97 so its possible that a workaround was found.
>
>Any info/insight would be appreciated.
>
>Thanks.
>
>
>Shigeki Misawa
>

-- Torre Wenaus, BNL      wenaus@bnl.gov      516-344-4755  Fax 516-344-4206 --
-- STAR Experiment, RHIC@BNL     Computing and software project leader       --
-- B. 510A Room 1-175            http://www.rhic.bnl.gov/STAR/computing.html --
--                               http://www.wenaus.com/torre.html            --