BdbExperience with Objectivity/DB

Table of contents:

• Found bugs, disadvantages and our bad experience

• Hints

Be careful ... found bugs, disadvantages and bad experience

Recently added

• (objy v5) ooattachdb -id too_big_number (larger then 65536), ooattachdb does not complain, instead it creates a database with modulo 65536 of specified number.
  Example:
      oonewdb -db testA
      oodeletedb -db testA -catalogonly
      ooattachdb -db testA -filepath testA.TT.DB -id 85536
      Id of attached db: 20000

• (objy v5)  It is impossible to turn off the information issued by ooattachdb :

First pass through ...
    Attaching database...TestDb
Second pass through ...
    Attaching database...TestDb

General

• Always #include the header file for Type in the ddl file of a class containing an ooVArray(type) as a member. See also Never, ever, EVER forward declare the type of an ooVArray

• never commit (or commit and restart) a transaction inside the function called on a persistent object (especially inside a constructor). In current BaBar release software this means: do not create a persistent object inside a constructor of another persistent object (complex clustering hint can decide to place this object in a new container or a database which force restarting a transaction). Commiting a transaction changes Objectivity's internal state of the handle, (references seems to be safer).

• deleting container does not call destructors of contained objects

• function ooHandle(ooContObj)::exist (const ooHandle(ooDBObj) &dbH, const char *contSysName, const ooMode openMode=oocNoOpen) called with the default parameter openMode=oocNoOpen does not set a handle (even if a container exists). Work-around: specify explicitly oocRead or oocUpdate mode. The bug has been reported to Objectivity.

• current implementation of AMS makes the system very insecure. Access to the database files is from the AMS Server rather than the client process, and that therefore conventional Unix file protection mechanisms cannot be used (since the AMS Server runs under it's own uid/gid rather than that of the client process)

• oodump seems to be of no use for larger amount of data

• varray of varray does not solve the problem of loading everything into memory at once, list of varrays does the job

• avoid static ooHandle or static ooRef - problems in destruction phase (static destructors cleans before objy destructor)

• when you delete an object, do not believe Objectivity will update all associations which reference that object. Click here to get an example.

• creation many databases in one job is much less efficient comparing to splitting the creation across many jobs

• d_activate(), d_deactivate() not implemented (part of ODMG)

• poor object deletion performance

• no API for ooattachdb. Workaround: call ooattachdb from a system() command.

• ooSignal() does not check the number of passed parameters. When wrong number of parameters passed, the function crashed with an error "No mapping to fault address". It is similar to fprintf.

Schema

• schema ids are NOT guaranteed, even if you compile the source in the same order on the same machine

• evolve flag can not be used if the class is introduced for the first time

• some transient types (e.g. ooVArray(ooDBObj) ) are places always in the default schema (not in named schema)

Replication

• any change to the schema -  requires all partitions to be online

• creation of a new database - ditto

• any other change which could change the quorum - ditto

• :-) Objy is aware of these "inconveniences" and is now working on improvement.

Lock server related problems

• lock can not be released remotely (lock caused by the application running on machine A has to be released from the machine A

• there is no easy way to kill a hanging transaction if the bootfile is unavailable (kill -9)

• do not start too many (~20) clients in the same second: possible lock server crash

Hints

  You can change a database name using oocopy, oodeletedb and ooattachdb with a different name

• schema IDs range: 1000 and up for objy types, all user types: 1000000 and up
• Objy does not reuses db IDs until it reaches the limit (65 K)
• ooSession class in not a part of official Objectivity product, probably it will be in the future

DB Home | BaBar Home | Computing | Online | Reconstruction | Simulation | Search

  Jacek Becla