1 / 17

An Interactive Browser For BaBar Databases

An Interactive Browser For BaBar Databases. Adeyemi Adesanya Stanford Linear Accelerator Center. Why?. We need an interactive Objectivity/DB utilities, for physicists and administrators Program supplied by vendor offers limited functionality and does not scale. BaBar’s Functional Demands.

lisahiggins
Télécharger la présentation

An Interactive Browser For BaBar Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. An Interactive Browser ForBaBar Databases Adeyemi Adesanya Stanford Linear Accelerator Center yemi@slac.stanford.edu

  2. Why? • We need an interactive Objectivity/DB utilities, for physicists and administrators • Program supplied by vendor offers limited functionality and does not scale yemi@slac.stanford.edu

  3. BaBar’s Functional Demands • Scalability! 64k database files • Presenting the right abstraction • No general external product is BaBar-aware • A logical, BaBar database hierarchy needs to be incorporated yemi@slac.stanford.edu

  4. Java • Suitability: • Comprehensive set of GUI components • Platform independent for wide deployment • Objectivity/Java binding has limitations related to language interoperability (today). yemi@slac.stanford.edu

  5. CORBA • A STANDARD for distributed inter-object communication (http://www.omg.org) • ORB’s form the middleware layer along with the IIOP • Java/C++ ORB bindings readily available yemi@slac.stanford.edu

  6. The framework • 100% Java provides the client GUI • C++ servers handle Objectivity access • 1 server process per Objectivity federation • NamingService stores server addresses yemi@slac.stanford.edu

  7. Key features • View the Database & Event collection hierarchy • Iterate through collections using simple selection (tags) • Access individual events and browse their headers • Identify “cloned” components • Scan a collection for databases yemi@slac.stanford.edu

  8. CORBA performance • A high-level protocol, not an alternative to TCP-IP! • Data marshalling is a major factor • Consider size/complexity of data types • Database IO overshadows CORBA latency yemi@slac.stanford.edu

  9. Minimizing the overhead • Server: Models the GUI components • No persistent objects are converted to CORBA • Transactions are kept as short as possible • Warn user of locking issues if necessary yemi@slac.stanford.edu

  10. The TAO ORB • Designed for real-time environments • Aim is reliable, predictable CORBA service • Optimized client & server stubs • Fine grained thread control yemi@slac.stanford.edu

  11. Multithreading • Reduce idle CPU time during IO tasks • Exploit multiprocessor hardware • Priority control • two models currently in use: • thread-per-connection • thread pool yemi@slac.stanford.edu

  12. Future: admin. tools • Browser database tasks strictly read-only • Develop separate GUI for administrators • Aid import/export of files between sites • Search engine • Drag and drop files and event collections yemi@slac.stanford.edu

  13. Summary • CORBA offers: • distributed object communication • platform interoperability • more than just a transport protocol • 100% Java for platform independent GUIs • Not all ORBs are created equally yemi@slac.stanford.edu

More Related