All About Read-only Databases
One of the attributes of an Objectivity database is a read-only flag. By default this flag is turned off. If all objects in a database are to be read, but not updated, you might consider turning on the read-only flag. It is important to understand pros and cons of the read-only mode before turning it on.
How does it work?
When a process accesses a read-only database for the first time, it must obtain a read lock on a special resource. That resource is global (one per federation). Once a process has that lock, it can access as many read-only databases as it needs without talking to lock server at all. Since there is no trace of the read-only access in the lock table, Objectivity has no way of determining what read-only databases are used by that process. That is why a read-only mode of any read-only database cannot be converted to read-write as long as one or more processes keep a lock on that special resource.
Any attempt to open a read-only database for update will fail.
Accessing read-only data does not generate any lock traffic. This is likely to speed up jobs, although the improvement depends on the load on the federation you are using, and how often containers in read-only databases are opened and closed.
From the user point of view, there are none.
From the administrator view, making a database read-only complicates maintenance where an attribute of a read-only database needs to be changed (for instance a database file needs to be moved to a different location: changing path or host):
- You cannot change an attribute of a read-only database; a read-only flag has to be turned off first.
- To turn off a read-only flag, the global resource guarding read-only access (described above) has to be unlocked. This means no process can access any read-only database. Usually this requires an outage.
BaBar Public Site | SLAC | News | Links | Who's Who | Contact Us
Page Owner: Jacek Becla
Last Update: June 13, 2002