Using shared database resources

In an ordinary application, one may refer to a single instance by a number of pointers or references. The instance, however, always resides in the same area in memory.

This becomes a bit more difficult when running a database application. Here, an instance might be element of several query results, or, especially in ODABA, the same instance or index (database resources) might be handled by different applications or several property handles within the same application.

Since indexes are not explicitly visible to the application, indexes are managed completely by the application. Instances, however, are subject of application controlled modifications and may cause conflicts, when being updated in multiple client applications.

The way, concurrent updates are handled and have to be considered within an application differs slightly depending on the selected client server model.

Updating an index is a short term action and while updating an index, the index is read locked for any other client. Indexes are checked for updates before each access. Detecting index modifications (increased modification count), the index will be refreshed.

Checking indexes for modifications is rather time consuming, but cannot be avoided, when running in multiple client environments. Different client server models solve this problem, but regardless on the server model, indexes accessed always reflect the proper state.

Nevertheless, updated indexes may cause minor problems. A typical case is the fact, that the position of an instance changes after an instance has been removed or inserted by another instance. Thus, calling Property::currentPosition() several times while an instance is selected in a property handle may return different values, when the index has been changed by another property handle. In order to avoid this sort of changes, the collection might be locked while accessing it (Property::lockCollection())

More critical is the situation, that an instance selected in the property handle has been removed from the collection by another property handle. In this case, the property handle state changes to unselected and the instance selected so far is not accessible anymore in the property handle.

When referring to an instance via different property handles (or via property handles in different applications), each property handle gets its own copy of the instance. This works fine, as long as the instance is not going to be updated. When updating an instance in one property handle, this becomes, usually, not visible in other property handles having the same instance selected. When storing an updated instance, an internal modification count will be increased, which allows other applications to recognize modifications.

Only property handles sharing the cursor will recognize changes immediately and may also update instances in parallel without problems.

When, however, changing different instance copies in different property handles, problems may arise, which have to be handled by the application. A save way for avoiding updates on an instance in different property handles is setting the property handle access mode to Write (Property::accessMode()). In this case, only the property handle, that selected the instance first will get write permission to the instance.

Changes in an instance will be notified to to other property handles after storing the updated instance, either by explicitly calling Property::save(), or by changing the selection for the updating property handle (implicit save). After the instance has been changed, other property handles may react on changes in the instance.

Most of the problems are handled by property handle functions, but in some situations, the application has to be aware about the fact of shared use of instances.