Sharing database resources between object server clients

The ODABA object server manages modifications on indexes and instances. On one hand, the object server behaves like an application, i.e. it manages instances and indexes accessed in different property handles. On the other hand, it passes instance data (no index data) to the client in order to be processed at client side.

Indexes are completely managed by the server and are not transferred to the client. Since the server automatically updates indexes whenever required, the position of an instance may change on server side without being noticed by the client. Checking the currentPosition() in the client application does not result in a server communication, but returns the always the position that has been passed with the instance when being selected in the property handle. Thus, is may happen, that Property::next() returns the same current position as the previous instance or a higher position, which is not the successor number of the previous position.

Since the object server behaves like an application sharing instances by different property handles, it will detect conflicts immediately after storing instance modifications to the database. In contrast to an ordinary application, the object server cannot avoid parallel updates for the same instance by different property handles.

Hence, any client request on property handle may result in a conflict reaction. E.g. when calling Property::count(), the server property handle might detect an update by another property handle and will refresh the currently selected instance and/or position. Since the count() function does not return data to the application, the instance on client side remains unchanged. In order to enable the client updating instances in case of unexpected changes, the server sends an update notification, which causes the client property handle to submit a subsequent reread of the instance.

When the instance on client side had already been updated, an exception is thrown and the instance is provided with the current state received from the server.

This may lead to unexpected exceptions caused by parallel modifications of the same instance. In order to avoid unexpected exceptions, the PropertyContext::notifyUpdate() handler should be implemented in order to handle refreshing the instance in the property handle before a conflict is detected.