public interface CacheSynchronization
dataBoundComponent
s or
programmatically on
dataSource
s directly, are reflected in the
client-side caches of other
dataBoundComponent
s. 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
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
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
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
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
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 dataSource
implementations.
These custom
DataSources will participate in cache sync like any other:cacheSyncStrategy
on the DataSource,
operationBinding
or dsRequest
RESTDataSource
, the default strategy for a custom dataSource
is "responseValues
"; this is primarily for backwards-compatibilityalwaysSync
" 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 fieldsalwaysSync
" 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
operationBinding
flags interact with the
above-documented behavior of CacheSyncStrategy
as follows:canSyncCache
is
false, no cache sync logic will
run at alluseForCacheSync
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 effectCacheSyncStrategy
,
OperationBinding.canSyncCache
,
OperationBinding.useForCacheSync
,
OperationBinding.cacheSyncOperation
,
DSResponse.getInvalidateCache()
,
OperationBinding.useForCacheSync
,
OperationBinding.cacheSyncOperation
,
OperationBinding.canSyncCache
,
DataSource.cacheSyncStrategy
,
OperationBinding.cacheSyncStrategy
,
com.smartgwt.client.data.DSRequest#getCacheSyncStrategy