1. M.Frank LHCb/CERN POOL persistency: Status  Current understanding  Today’s model  Conclusions

2. M.Frank LHCb/CERN 2POOL Persistency – What is it about? Objects & pointersObjects, object IDs, collections & DBs Transient Persistent C++ pointer => object ID

3. M.Frank LHCb/CERN 3POOL The Object Model (June)

4. M.Frank LHCb/CERN 4POOL Cache Access Through References  References know about the Cache Manager  References are implemented as smart pointers  Use cache manager for “load-on-demand”  Use the object key of the cache manager Object Identifier in Cache Manager Reference to Cache Manager Ref Pointer to object Dereference

5. M.Frank LHCb/CERN 5POOL Cache Access Key CacheMgr Pointer SmartRef Cache Manager Persistency Manager Token Storage Type Object Type (GUID) Persistent Reference KeyObjectToken ……… 2

6. M.Frank LHCb/CERN 6POOL The Object Model (June)

7. M.Frank LHCb/CERN 7POOL Class Diagram of Today

8. M.Frank LHCb/CERN 8POOL Typical Calling Sequence

9. M.Frank LHCb/CERN 9POOL Persistency Interface  Read Object access  readObject  Transaction handling  Start, commit, rollback  Register objects for writing

10. M.Frank LHCb/CERN 10POOL Writing Objects  Supported by IPersistencyMgr  Start transaction  Loop 1 … n  Mark objects for write: requires placement hint  End Transaction  Commit  Rollback (if supported by database)

11. M.Frank LHCb/CERN 11POOL Model Assumptions Data Cache StorageMgr Disk Storage database Database Container Objects Class GUID Cache hints [0..*] Storage type DB name Cont.name Item ID

12. M.Frank LHCb/CERN 12POOL Link ID Link Info DB/Cont.name,...... Local lookup table in each file Follow Persistent References Entry ID Link ID XID (2)(3) (4) (1) KeyObjectToken 1 2---------------

13. M.Frank LHCb/CERN 13POOL The Link Table  Contains all information to resurrect an object  Storage identifierINT  Database “name”string  Container namestring  Class identifierGUID  Cache hintsstring []  E.g. other possible transient conversions Make sure the object model does not go wild!

14. M.Frank LHCb/CERN 14POOL Conclusions  I think this model could work very nicely for any persistency technology based on database files, collections and objects within collections  The main thinking is done  Think about some optimizations, which cannot be introduced later  Looks like it’s about time to start prototyping

15. M.Frank LHCb/CERN 15POOL Persistent Objects What is the default?  Objectivity, OOCI:  Everything is persistent unless deleted before commit  ROOT, RDBMS:  Nothing is persistent unless explicitly saved  ROOT: Tobject::Write(), Ttree::Fill() etc.  RDBMS: INSERT INTO VALUES (…)  …has consequences on allocation mechanism

16. M.Frank LHCb/CERN 16POOL Persistent Object Allocation First possibility:  During “Mark objects for write”  In registerObjectForWrite(…)  Client can know immediately if object can be written  Better handle for corrective actions  Create persistent token  In endTransaction(…)  Fill data, resolve references and update row “unregisterObjectFromWrite” difficult Transaction may be open for a long time

17. M.Frank LHCb/CERN 17POOL Persistent Object Allocation Second possibility:  During “End Transaction”  In markObjectForWrite(…)  Trivial. Simply collects object pointers  “unregisterObjectFromWrite” trivial  In endTransaction(…)  Create persistent token  Fill data, resolve references and update row Only bulk transaction/conversion status On failure drop all