Sharing database resources between local and replication server clients

When several local clients are accessing a database using file server functions, applications have to be aware about possible asynchronous updates. Database clients are different processes on one or more machines, but also different threads in a multi-thread application. Each client caches and manages database resources separately. Since local clients do not know each other, no update messages can be send to other clients. Thus, each client has to check for changes made on database resources.

This is a bit time consuming, but it is still an acceptable performance for this simple client/server model.

Local clients behave similar to replication server clients, with the only difference, that each replication server client has got its own database copy, which is updated by the replication server.

Index updates are critical and have to be checked each time before accessing an index. Thus the database makes sure, that instances are always up to date when being accessed. This causes loss of performance, which is the price for the simple client/server model.

When sharing database instances in a network, instances accessed by one client might be updated by another client. Updated instances, i.e. instances, which are stored to the database after transaction commit, become visible to other applications, as soon as the instance will be accessed.

After selecting an instance in a property handle, it will not react until the application explicitly refreshs the selected instance. Thus, updated in an instance made by another client usually are displayed with some delay.

When accessing a selected instance (e.g. in order to extract values from the instance) the instance is not checked for updates from other clients. In order to receive updates from other clients, the selected instance has to be refreshed (Property::reset()).

When accessing instances in Update mode, several clients may modify an instance in parallel. In this case, the first client, that saves the instance, will succeed. Other clients, that try to save modifications will react with error 67 (trying to update a modified instance) and throw an exception, since the instance state provided for update is not up to date. Since saving the instance might be an implicit action when changing the selection in a property handle, it is suggested calling save explicitly in order to avoid unexpected exceptions.