You are here: Client-Server > Reference Cache In Client-Server Mode > Refreshing Objects

Refreshing Objects

When working with multiple client object-containers each container has its own reference cache. When you query for objects, you get always the cached objects. This means, that objects probably have been updated in the mean-time but the client still sees the old state.

For some scenarios you might need to refresh to objects to bring it up to date. There are two strategies for this. You can explicit refresh a object at any time. Or you can use callbacks to refresh object on each commit. Both methods have their advantage.

  Explicit Refreshing Using Callbacks
Advantage
  • Selective refreshing possible, which reduces network traffic.
  • Can decide when a refresh is required. If no refresh is required, you can save the network traffic.
  • The objects are always up to date.
  • There's no need to explicitly refresh-calls in your data-access layer.
Disadvantage
  • Partial refreshed objects may lead to a inconsistent object-graph.
  • Probably a lot of refresh-calls spread over the code-base.
  • A lot of network traffic is required to send the committing-events and object to the clients.

Explicitly Refreshing Objects

You can refresh objects with the refresh-method on the object-container. The pass the object to refresh and the refresh-depth to the method:

db.Ext().Refresh(objToRefresh, int.MaxValue);
RefreshingObjects.cs: refresh a object
db.Ext().Refresh(objToRefresh, Integer.MaxValue)
RefreshingObjects.vb: refresh a object

Using Callbacks For Refreshing Objects

You can use the committed-event to refresh objects as soon as another client commits. Take a look at the example: See "Committed Event Example"