com.smartgwt.client.docs

Interface CacheSynchronization

public interface CacheSynchronization

Automatic Cache Synchronization

Cache synchronization is the mechanism used by Smart GWT to ensure that updates made by dataBoundComponents or programmatically on dataSources directly, are reflected in the client-side caches of other dataBoundComponents. Automatic cache sync means that components update themselves to reflect data changes - so if you update a record in a form, and the same information is currently visible in a grid, the grid data will change to reflect the updates automatically. Cache synchronization has been a feature of Smart GWT for a very long time, but in release 13.1 it was revamped to offer more flexibility and various performance-friendly options.

CacheSyncStrategy

Cache sync configuration revolves around the new CacheSyncStrategy type. This allows you to define a cache sync approach globally, per-DataSource, per-Operation or per-request. See the CacheSyncStrategy documentation for details.

CacheSyncStrategy support with different DataSource types

The most extensive automatic support for CacheSyncStrategy in Smart GWT is provided by SQLDataSource, but the concept applies to all dataSource types. The following section describes how CacheSyncStrategy applies to various built-in dataSource types

SQLDataSource

SQLDataSource supports three of the four default cache sync strategies: alwaysSync, syncForClientResponses, and requestValuesPlusSequences. responseValues is not supported, because an SQL update operation does not return a response.

Sequence values are retrieved according to the sequenceMode. For the best performance, use a JDBC 3.0+ driver, and a sequenceMode of "jdbcDriver". This effectively gives us the sequence values for free, avoiding the native database query we have to run if the sequenceMode is "native"

HibernateDataSource and JPADataSource

HibernateDataSource and JPADataSource only support alwaysSync. These two implementations integrate with the underlying ORM system at the level of the ORM's API, allowing it to handle the details of database interaction. With these two DataSource types, we are simply working with "persistent objects" - how the ORM manages things like changes made by the database during update queries, or sequence values in add operations, is the ORM's business.

For this reason, HibernateDataSource and JPADataSource install a special CacheSyncStrategy implementation under the alwaysSync name, that just does nothing, leaving the response data returned by the update operation unchanged.

RESTDataSource

RESTDataSource supports all four of the default cache sync strategies. alwaysSync and syncForClientResponses involve a second round-trip to the REST service, so may be a performance concern.

requestValuesPlusSequences attempts to extract the values for any missing primaryKey fields from the response sent by the REST service to the add or update request, so it is obviously only of use if the REST service returns such values.

responseValues, the default strategy for RESTDataSource, just uses the response data sent by the REST service to the update or add request. Again, this is only usable if the REST service returns such data, but if it does, this strategy is ideal.

Custom/Generic DataSources

In addition to the built-in DataSource types listed above, you can of course write your own custom dataSource implementations. These custom DataSources will participate in cache sync like any other:

• You can specify a cacheSyncStrategy on the DataSource, operationBinding or dsRequest
• Like with RESTDataSource, the default strategy for a custom dataSource is "responseValues"; this is primarily for backwards-compatibility
• If you want to use "alwaysSync" or "syncForClientResponses", you must implement a fetch operation, and if your dataSource has fields of type "sequence", your fetch mechanism must able to resolve the values of such fields

Note that "alwaysSync" behaves the same as "syncForClientResponses" with a custom dataSource; the refetch is done lazily, and it is not done at all if nothing asks for the response data. This is because the integration with cache sync happens when the server-side DSResponse's setData() method is called. This happens automatically and will work perfectly for most use cases. If, however, you have some unusual requirement which means you need "alwaysSync" to cause an immediate cache sync fetch like it does with the built-in dataSources, you can do what they do: invoke the CacheSyncStrategy manually from your execution flow, like this:

     CacheSyncStrategy strategy = dsRequest.getCacheSyncStrategy();
     if (strategy.shouldRunCacheSync(dsRequest)) {
         // Apply the cache sync data to the dsResponse, first fetching it if necessary
         strategy.applyCacheSyncStrategy(dsRequest, dsResponse)
     }
  

canSyncCache, cacheSyncOperation and useForCacheSync

These three long-standing operationBinding flags interact with the above-documented behavior of CacheSyncStrategy as follows:

• If canSyncCache is false, no cache sync logic will run at all
• If a useForCacheSync operation is in force, or the update operation specifies a cacheSyncOperation, that operation will be run if we are refetching the updated record - ie, if the cacheSyncStrategy is alwaysSync or syncForClientResponses. In the latter case, the operation execution will be deferred and may not run at all, as described in the documentation for that strategy. If we are not refetching the updated record, these two flags have no effect

See Also:

CacheSyncStrategy, OperationBinding.canSyncCache, OperationBinding.useForCacheSync, OperationBinding.cacheSyncOperation, DSResponse.getInvalidateCache(), OperationBinding.useForCacheSync, OperationBinding.cacheSyncOperation, OperationBinding.canSyncCache, DataSource.cacheSyncStrategy, OperationBinding.cacheSyncStrategy, com.smartgwt.client.data.DSRequest#getCacheSyncStrategy