Updates and Work Units
Page 3 of 4

Controlling Update Behavior

Cloudsync provides two types of updates:

  • Changed-Value Updates

    The default strategy, requiring no additional coding on your part. Use only when conflicts are not expected.

  • Work Units

    Let you determine exactly how you want the update to be handled. Use when there are possible conflicts or when you want to take special action, such as sending an email message.

Changed-Value Updates

By default, the data changed by a target transaction simply replaces the current source data during the refresh unless a constraint prevents it. The value of a column in a given row in the target database replaces the value in the corresponding row in the source database.

There are situations in which Cloudsync's default update strategy works well; for example:

  • All changes are made directly at the source; the targets are all read-only.
  • There is only one read-write target and the source is never updated except by that target.
  • No two targets change the same data.

In these conflict-free cases, simply make changes to the target database (if appropriate), then run a refresh to send changes to the source or to receive updated changes from the source. When deciding whether to use changed-value updates, consider whether the source database will be upgraded. In these situations, work unit updates are preferred.

Work Units

A work unit is a Cloudsync entity consisting of logical operations that update data (or perform other operations) upon refresh. A work unit consists of one method at the target and one method at the source. These source- and target-side methods may be identical, or they may differ because the target database may not contain all of the source database's dictionary objects or data, or for any other reason useful to the application. Work units provide a way to handle conflicting updates from multiple targets using logical operations rather than just blindly copying data.

This section discusses the following topics:

NOTE: To increase security, you can publish the cloudscape.synchronization.workUnitOnly property which forces a target to accept only work-unit updates. Specifying work unit-only updates also provides more flexibility when upgrading the source database. See cloudscape.synchronization.workUnitOnly for details.

Understanding Work Units

When conflicts are possible, you may not want a target value to simply replace the source value. For example, consider a Web-based toy sales application. Say that customers at Target A and Target B each issue a refresh at the beginning of the business day. At 9:00 a.m., both targets show that there are 10 available Barbie dolls. At 9:05, a customer using Target A orders three Barbies, reducing the number of Barbies known to the target to seven, then issues a refresh. The source database then shows that seven Barbies are available. At 9:10, a customer using Target B orders one Barbie, changing the apparent availability of this doll on Target B to nine. Target B then refreshes, causing the source database to incorrectly show the number of available Barbies as nine, rather than reducing it to six. This update causes the source to incorrectly record inventory. Changed-value updates from the target cannot handle this situation correctly; for example, using changed-value updates, you cannot tell the source to reduce the inventory of Barbie dolls by three.

To handle conflicting updates from multiple targets, Cloudsync allows you to use logic rather than forcing you to copy data. In the case of the toy sales application, each target can invoke a procedure telling the source to reduce its inventory by a certain amount, rather than just copying the value indicating the number of Barbie dolls in stock. This procedure could also tell the source to back-order an item if there were none available, and it could say what to do if an application-defined exception occurred.

Work Units are Applied Provisionally

Like changed-value updates, the target-side work unit method is applied provisionally to the target at the time it is invoked. Also like changed-value updates, the target-side work unit method is under transactional control and thus either provisionally commits or rolls back. Unlike changed-value updates, however, the source-side method, rather than the provisional target data, is applied durably at the source at refresh time.

For more information, see the section Transactions and Work Units.

Work Units Operate from Target to Source

Work units determine how target data is written to the source, but they have no effect on how source data is written back to the target. The refresh operation uses changed-value updates to replace the target with a more recent version of the source. This preserves agreement even if the work unit makes different changes each time it is run. Because refresh sends work unit logic from target to source, and consistent data from source to target, Cloudsync's synchronization strategy is called LUCID--logic up, consistent information down.

Like other target changes, the work unit's target-side method has only a temporary effect on the target data. The results of the target-side method remain on the target only until the end of the refresh cycle, since the results of the source-side method are written back to the target at that time.

Since work unit methods are normal Java code, they are not restricted to database updates: for example they can also send an email message.

Work Units Are Method Aliases

Work units are essentially synchronization-enabled method aliases. (See the Cloudscape Reference Manual for more information on method aliases.) When you call a non-synchronization method alias, a single method is called. When you call a work unit, two methods are called: the target method is called when the work unit is invoked at the target, and the source method is called when the transaction is applied at the source during the refresh. Parameters invoked with the target work unit method are also available to the source method.

Like method aliases, work units:

  • are registered with a CREATE WORK ALIAS statement
  • are invoked using the CALL or VALUES statements
  • are implemented as public static Java methods
  • can return values

Unlike other static methods called by SQL-J, work units are atomic, meaning that commits and rollbacks are not permitted in either method of the work unit.

Benefits of Work Units

Work units provide the following benefits:

  • They allow you to apply application- or business-level logic rather than database-level logic during a refresh.
  • They allow you to handle conflicts between target changes and source data.
  • They provide transactional atomicity to the actions in the work unit.
  • They provide flexible error handling.
  • They provide increased flexibility for upgrades to the source database.
  • They make your system more secure; with changed-value updates, target users can modify or delete the entire subset of data they have access to. With work unit updates, the application programmer defines the actions that users are allowed to do.