cacheUpdates

Topic group Related topics

Whether to cache updates locally instead of writing to disk as they occur.

Property of

Database

Description

Normally, when a row buffer is saved, it is written to disk. By setting the cacheUpdates property to true, those changes are cached locally instead of being written to disk. One reason to do this is to reduce network traffic. Changes are accumulated and then posted with the applyUpdates( ) method, after a certain amount of time or a certain number of changes have been made.

Another reason is to simulate a transaction when you have more than one change in an all-or-nothing situation. For example, if you need to fill a customer order and reduce the stock in inventory, you cannot let one happen and not the other. When the changes are posted with applyUpdates( ), they are applied inside a transaction at the database level. Because you cannot nest transactions, you cannot have a transaction with beginTrans( ) and use cached updates at the same time. If any of the changes do not post, for example one of the records is locked, all of the changes that did post are undone and applyUpdates( ) returns false to indicate failure. The cached updates remain cached so that you can retry the posting. If all the changes are posted successfully, applyUpdates( ) returns true.

Finally, because of the all-or-nothing nature of cached updates, you can use them to allow the user to tentatively make changes that you can simply discard as a group. For example, you could allow a user to modify a lookup table. If the user submits the changes they are applied, but if the user chooses to cancel, any changes made can be discarded by calling the abandonUpdates( ) method. Note that with cached updates, the changes aren’t actually written until posted. In contrast, transaction logging actually makes the changes as they happen, but allows you to undo them if desired.