stale record checking

[kedaar]

Hi,

In our application there are other applications that write to the database and may cause the data that the user is seeing in their browser to become stale.

I have read this post:
http://forums.smartclient.com/showth...tale+dsrequest

It appears that oldValues gives you the unedited record from the client, and newValues give the newly updated record. I dont see a public method on com.isomorphic.datasource to read the existing record from the database (which may have been changed by another user).

Thanks

[SiccoNaets]

Kedaar, I had a similar requirement in my application and eventually worked out a solution. The existing SmartGWT code base can be used to solve this; all the required logic is there.

As you correctly observed, a ListGrid holds a client-side (stale) version of a record as the record existed at the ListGrid was populated. When you pass that record into a form, via, for instance, a recordClickHandler or a recordDoubleClickHandler; you're passing the stale version. The form, by default, will not round-trip back to the server and get the lastest version.

In order to get around this, I instead wrote the clickHandler in such a way that rather than passing the record; it passes the ID of the record to the form. The form then has an editRecord(Long id) method; which given a ID, allows it to load the record from a datasource and calls editRecord(Record record) in an asynchronous callback. So; rather than the listgrid loading the record and then sticking it in a form; I instead let the listgrid load the record, then pass the id to the form; and then let the form load the record itself.

This ensures that the form has the most recent version of the record, regardless of what the listGrid was showing. It also allows you to implement a "reload" button fairly easily. The downside of course is that the application becomes more "chatty" - you'll see more roundtrips back to the server; but since the form is only asking for single records; this shouldn't be too bad.

In and of itself, this isn't sufficient to prevent overwriting a record with stale data though. Yes, the form will now load the most up-to-date version of a record when it's first loaded... but if the user lets the form sit for a while (maybe they open the form and then go for lunch), the data could still be stale on submit.

In order to address that, all my underlying domain objects have a version attribute. This version attribute is incremented when the object is updated. By adding the version attribute to the datasource and letting the form submit it as part of it's update call; you can check the version of the client record with the version of the server record and throw an error back to the client if the server version is newer than the client version.

Incidentally, it's important to use something like a version number and not a timestamp. I went down that road first and I found that javascript (which is, at the end of the day, what SmartGWT gets turned into) rounds timestamps differently from java; so that in some cases, the server-version appears to e newer than the client version, even though this isn't the case (basically, javascripts shaves a few miliseconds of the datetime stamp when it's passed back to the server).

Hope that helps