com.smartgwt.client.docs

Interface ConcurrentEdits

public interface ConcurrentEdits

Handling concurrent edits in Smart GWT DataSources

How do Smart GWT DataSources handle multiple users making changes to the same record?

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:

• userA makes a change to a record and saves the edit
• userB then makes another change to the same record and saves their edit

By default Smart GWT dataSources have simple "most recent edit wins" behavior, so the changes made by userB will be preserved in the dataSource permanent storage - though if DataSource.sparseUpdates is 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:

Broadcasting changes:
The 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 appropriate.

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.

Detecting concurrent edits:
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.