You might think that only one database would be required to hold the object state information described above. Why, then, are three backing store databases employed in the sample application? The answer to this question has two parts.
First: It is true that only one database is needed to hold the object state information itself. The need for a second database arises from the necessity of organizing the object information in more than one way, so that it can be retrieved both by name and by object UUID. The object information is stored directly in a database indexed by object UUIDs, and that is how it must be retrieved. However, application users will specify resources by names, not UUIDs. In order to make this work, the application stores its objects' UUIDs in a separate database indexed by their names. Thus any object's information can be retrieved, if the object's name is known, by means of a two-step process involving (first) looking up an object UUID from the name-indexed database, and (second) looking up the object information from the object UUID-indexed database.
Secondly: There is a third database to hold only the objects' ACLs. Theoretically speaking, there is no reason why the ACLs couldn't be held with the rest of the objects' information, in the object UUID-indexed database. However, the application's ACLs must be accessible to the DCE ACL library routines, and these routines expect a database, indexed by ACL UUIDs, containing only ACLs.
This allows us, for example, to call a DCE routine such as dce_acl_is_client_authorized( ) (see the sample_mgmt_auth( ) callback routine in sample_server.c), passing the ACL manager type UUID and the ACL UUID, and get back an answer to some query about permissions - the library routine is able to go into the database and access and read the ACL; we don't have to bother with that. It also allows the rdacl implementations in the ACL library to do the same thing, since they have a full ACL binding (which includes a handle to the database in which the ACL is stored).