public interface ConcurrentEdits
Consider a scenario where two users - userA and userB - are logged into the same application and viewing the same set of records in a Smart GWT application:
saves the edit
DataSource.sparseUpdatesis false, any changes made by userA to fields that were not explicitly edited by userB will also be preserved.
In this case when userA performs their first edit (before userB has attempted a save), userB will not see userA's changes unless they explicitly re-fetch the data. Similarly, userA will not see userB's subsequent edit without a re-fetch.
In many applications this behavior is acceptable but there may be cases where users will need to see other users' updates as they occur, and simple "last edit wins" is not sufficient. There are 2 things you can do to make this more sophisticated:
DataSource.updateCaches() method is a way to
notify a DataSource that a change has occurred. It will update its client-side caches to
reflect the change and databound components showing the record will be refreshed as
Developers using the Smart GWT server and
Messaging may use this feature to propogate changes from the server
to the client.
See this blog post for details on this approach.
Note that even if an application is using Realtime Messaging or some similar approach to notify users of external edits as soon as they occur, it is still possible to get concurrent edit attempts on the same record.
In our original scenario - if userB hit their save button after userA but before the server had processed userA's request, userB's edit would essentially be based on "stale" values.
One way to
detect this is to have custom server logic compare
DSRequest.oldValues with the current values
for the edited record and disallow the edit when this occurs.
See this blog post for details on using oldValues to detect concurrent edits.