1. Prelude Many questions/points have been raised in recent weeks, and forwarded by David Stickland to me: n Views on storage technology choices n Views on hybrid store common project n Project mandate and organization n Current technical approaches and their deficiencies n OIDs and reference requirements n Component definitions, structure, and interrelationships Following slides are therefore broad but not deep

2. Non-technical background n Official ATLAS position has been (cf. Computing Technical Proposal) to use common solutions (in particular, common to LHC experiments) where possible n This is the reason for the current ATLAS baseline storage technology choice, which is Objectivity n This is why, for example, we are trying to base our conditions db work on IT-provided infrastructure n Consonant with this, I (and others) would have difficulty endorsing a strategy in which ATLAS were the only LHC experiment using Objectivity –Same would be true of Oracle 9i, of course, and of other commercial technologies, even outside the database realm

3. On Objectivity in particular n ATLAS core software view is, in the now-famous words of the Marseilles LHC software workshop, that Objectivity “can be made to work” n We have seen no technical showstoppers n Widespread ATLAS experience has been (frustratingly) limited, but NOT primarily because of the technology choice n Our architecture, nonetheless, neutralizes many of the advantages of an object database (and potentially of other technologies as well)

4. On hybrid solutions n We have already taken a “component-oriented” approach to our data stores –No assumption that all data are stored in single technology n At last summer’s IT-sponsored LHC database workshop, in discussions of common projects and near-term priorities, I proposed a look at hybrid approaches, rather than exclusive emphasis on Oracle 9i homogeneous solutions –Proposal based on what I heard from ALICE and LHCb—not CMS—at that time

5. Hybrid solutions in ATLAS n ATLAS has both an Objectivity conversion service and a ROOT conversion service in current software releases n ROOT work is based on STAR approach (STAR dependencies have been excised), and is aimed at ROOT+relational hybrid n If a common project produces a common ROOT streaming layer approach, we plan to use it n Explicit milestone: technology evaluation involving Objectivity and ROOT in 2002 (context is Data Challenge I, Phase II)

6. ATLAS database architecture n We have a draft database architecture document, presented to collaboration in September –Ed Frank, with help from Greg Chisholm, took on the unenviable task of turning wide-ranging, conflicting discussions into a strawman architecture proposal –Review planned for early next year (we hope) n Intended to be technology-neutral –Held two-day meeting with BNL ROOT experts/advocates to ensure no unintended technology bias n ATLAS BNL group is producing a design document describing how one might realize the ATLAS database architecture in a ROOT/relational implementation

7. On the common project process n Unhappy with the way this came about: “let’s write a mandate on Thursday afternoon for an LHC-wide working group to meet three days a week beginning next Monday morning” n We all claim to be global collaborations—let’s conduct our business as though this were true n Don’t quite understand whether this effort pre-empts LCGP process, or merely predates it n Don’t quite understand how priorities are set: based on Kasemann panel review, one might have expected a first common project on what Vicky White calls the data management side (as opposed to the persistence side): –My spin: when we all have 5,000,000 2-GB files, how much of our problem will be related to the format of data inside those files?

8. On to more technical issues… n Object id and object location are often confounded –Answer to question “which object” is often “the one at location X” –Not unique to databases: this is what happens when one wants to indicate which T to pass to a method in C++ (“the one whose location is…” (pass a pointer)) –Programming languages often provide no help here

9. OIDs n “Logical” locations help, but do not solve the problem –E.g., OID contains database number, with an additional mapping layer to support translation to physical file name –Replication, object relocation, reclustering issues remain n See Dirk’s slides for “range of implementations” overview n Some technologies attempt to use something close to a “location-independent” OID, but often suffer from performance problems n In hybrid approach, there are natural places to reconsider this issue

10. ATLAS architecture n ATLAS has taken a rather stringent view of transient/persistent separation –Based largely on Gaudi—see Markus Frank’s slides –Tends to imply explicit copying in practice n Did you ever see Objectivity’s “N reasons to choose an object database”? n Reason #1 is “lose that mapping layer” n ATLAS architecture REQUIRES that mapping layer

11. On references n Even with explicit copying, the fact that transient A points to transient B does NOT imply that persistent A points to persistent B n See Markus Frank’s slides n Entirely possible to write an implementation in which the only persistent pointers within an event are managed by the event header, not by any data objects that are part of the event, despite inter-object associations –We’ve done it n COULD move even these pointers into relational layer in a hybrid solution n IMPLICATION: object streaming technology need not a priori support persistent pointers at all

12. Cache Management n Athena has its own caches (transient stores) and cache manager (StoreGate) n Writing one’s own cache manager is often a bad idea, particularly when it’s fed by another product doing its own cache management, implemented on an OS’s cache management, … n Does provide certain advantages (tuning caching to particular data types or uses) –Certainly a locus for lifetime management –Can also answer the question “which T” with “the one whose version is V and whose time interval of validity contains t”)

13. Interfaces and ATLAS requirements n “Independence of database supplier” (an ATLAS tenet) means that we want to see discussions of interfaces in terms of relational plus object streaming layer, NOT {“specific relational product” + “specific streaming product”} n Consonant with component-oriented approach: components should be replaceable n Implementations are another matter: if the only known streaming layer implementation is ROOT, that’s okay (we do not plan to invest time any time soon in writing our own alternative, in any case)

14. (Unique?) ATLAS requirements? n ATLAS is attempting to describe both interfaces to transient data objects and data object state in an implementation-language-independent way –ADL, based on IDL –Anticipate that this will play a vital role in multi- language support n Possible streaming layer implications: –Definition of object to be streamed is not in C++ –Should certainly not assume C++  C++