Access requirements

Supposed all specifications you made for a property handle hierarchy are correct, there are some additional important rules to be taken into account, when accessing properties in a hierarchy.

• A property handle is accessible only, when it is the top property handle in a hierarchy or when the parent property handle is positioned or contains an initialized instance (instance selected). Otherwise data access functions will terminate with an odaba::Exception .
• When changing the selection in a property handle, all subordinated property handles become unselected.
• When a property handle becomes unselected, all subordinated property handles become inaccessible, i.e. data access functions terminate with an exception. Metadata access functions, however, might be called, as well as open() functions and Value or Property constructors.
• When selecting an instance in a property handle opened in write mode ( Write ), the instance is locked (pessimistic write lock). When this is not possible, because the instance is locked by another property handle or application, the instance can still be selected, but is accessible read-only.
• When selecting an instance in a property handle opened in update mode ( Update ), selected instances are locked (optimistic write lock). When saving changes for the instance, possible conflicts will be detected. In case of a conflict the application can decide whether to discard the current changes or overwriting the changes made by the other application or property handle. We suggest, always to discard the changes made on the currently selected instance (default).

There are other rules described later on, but those are the most important ones.